Hello and welcome to this lecture which will summarize some of the key points mentioned throughout the previous lectures. I started this course looking at User Groups and in this lecture we learnt that: IAM User Groups can be used to manage multiple users. They do not signify a single user and can't be referenced within an IAM policy. They contain IAM Users and have IAM policies associated with them defining their permissions. They are normally created to directly relate to a specific requirement or job role. Applying these permissions to a Group instead of individual users is a security best practice.

To create a Group is very simple and is essentially a 3 step process: Give your Group a meaningful name. Add users to the Group. And then attach permissions via policies. There are limitations on the number of groups per AWS account and for the latest information on this please refer to the following url. I then focused on IAM Roles to understand how they can be used to help manage access. I started by explaining that IAM Roles: Allow trusted Users, AWS services and applications to adopt a set of temporary IAM credentials to access your AWS resources. They are designed to be assumed by multiple different entities as and when required.

Each time a role is assumed a new set of dynamic credentials are created. IAM Roles do not have any long term credentials associated with them. Roles have associated policies controlling access as to what can and can't be accessed when the role is assumed. A Trust Relationship defines who or what can assume the role. IAM Roles are generally used: To grant temporary access for Users in your account or cross-accounts. For AWS Services to carry out specific operations on your behalf. Or for federated uses. I then explained what AWS Service Roles were and what they were used for, and in this section I covered the following points: AWS Service Roles allows AWS services to assume a role to access other AWS resources within your account on your behalf.

Commonly used for EC2 instances. AWS managed and customer managed policies can be attached to Service Roles. Service Roles can be attached to an EC2 instance during its creation or when its running. It's a security best practice to associate a Role to an EC2 instance for accessing AWS resources instead of storing local credentials on the instance itself. There are a number of AWS Services that integrate with IAM that support roles. Service-linked roles perform functions requiring very specific permissions which are often created the first time you use the service.

Service-linked Roles come pre-configured with the relevant AWS Managed policies, trusts and permissions allowing only that Service to carry out the required operations. The difference between AWS Service and AWS Service-Linked Roles is that AWS Service roles allow you to apply your own customer managed or AWS Managed policies, whereas service-linked roles come pre-configured with a specific set of read only AWS managed policies that can only be used by that particular service. Following Service Roles I then looked at IAM User Roles to understand how individual users can adopt a set of temporary credentials.

During this lecture I explained that: When a User assumes a Role it replaces all other permissions that the User has. To assume a role you need to be a trusted entity and have access to assume the Role via a policy. IAM User Roles are often used to create cross-account access, allowing users in one AWS Account to access resources in a different AWS account.

Finally I covered how Roles are used to grant access to federated users which involved both Web Identity federation and SAML 2.0 federation. When discussing Web Identity I explained that: Identity Federation is basically an access method of authentication where two different providers can establish a level of trust allowing users to authenticate from one, which authorizes them to access resources in another. AWS would act as a Service Provider.

A Web Identity Provider would be Google or Facebook, for example. When users authenticate via web identity federation, they will receive an authentication token. The token is then exchanged for temporary security credentials in AWS and mapped to a Role providing access. Amazon Cognito is the preferred method for managing federated access for mobile applications. When I covered SAML Federation I covered the following points: SAML 2.0 is generally used to authenticate your employees using existing directory services that you might already be using, such as MS AD. It minimizes the amount of administration required within IAM allowing for a single sign-on solution.

The Security Token Service allows you to gain temporary security credentials for federated users via IAM, associated with IAM roles and policies. That now brings me to the end of this lecture and to the end of this course, and so you should now have a greater understanding of IAM User Groups and how they can be used to simplify access management across multiple users, and how IAM Roles provide short-term temporary credentials to your users and AWS Services.

Feedback on our courses here at Cloud Academy is valuable to both us as trainers and any students looking to take the same course in the future. If you have any feedback, positive or negative, it would be greatly appreciated if you could contact support@cloudacademy.com. Thank you for your time and good luck with your continued learning of cloud computing. Thank you.