Hello, and welcome to this lecture, where I am going to define the user, group and role objects within AWS IAM, and the differences between them. Following this, I'll provide a demonstration on how to set up and configure all three. Let's start with users.

Users are objects created to represent an identity. This could be a real person within your organization who requires access to operate and maintain your AWS environment. Or it could be an account to be used by an application that may require permissions to access your AWS resources programmatically. Users are simply objects representing an identity which are used in the authentication process to your AWS account.

When creating a new user, you have the option to create it via the AWS Management Console, or programmatically via the AWS CLI, Tools for Windows Powershell, or using the IAM HTTP API. For this and other lectures, I shall be using the AWS Management Console to demonstrate how to configure various elements of AWS IAM.

User object creation involves the following seven steps. Setting user details, by creating a user name, which can be up to 64 characters in length. Next, you'll select the AWS Access Type, either AWS Management Console Access, or programmatic access. To use the AWS Management Console Access, the user will need to be issued with a password.

For programmatic access, an access key ID and secret access key ID will be issued to be used with the AWS CLI SDKs or other development tools. You'll then need to define a password, if AWS Management Console Access was requested. Then, permission assignment for the use of policies attached to the user itself, or inherited from a group that the user can be assigned to, and you'll then need to review and confirm the information.

After this point, the creation of the user will take place, then you can download the security credentials within a CSV file, that will contain the user name, keys required for programmatic access, and the console login link, etc. These details can also be emailed to the new user, using the send email link.

I just want to cover a point I mentioned in step two. Access keys, which are required for programmatic access for authentication. These access keys are comprised of two elements, an access key ID, and a secret access key ID. The access key ID is made up of 20 random uppercase alphanumeric characters, such as the one on the screen.

The secret access key ID is made up of 40 random upper and lowercase alphanumeric and non-alphanumeric characters, such as the one displayed on the screen. During the creating of a user who requires programmatic access, you are prompted to download and save the details, as the secret access key ID will only be displayed once, and if you lose it, you will then have to delete the associated access key ID and recreate new keys for the user.

It's not possible to retrieve lost access key IDs as AWS does not retain copies. These access keys must then be applied and associated with the application that you are using, that requires the relevant access. For example, if you are using the AWS CLI to access AWS resources, you would first have to instruct the AWS CLI to use these access keys to authenticate and provide authorization.

The method of performing this association varies based on the application and system that you're using. However, once this association has taken place, it ensures that all API requests made to AWS are signed with this digital signature.

Once your user identity is created, you can view a summary of the object by selecting user, from within the user page of the console. This will show the user ARN, which is the Amazon Resource Name, which is a unique identifier of the object, the creation time of the user object, any attached policies that are associated with the user, any group memberships that the user belongs to, the details of the security credentials of the user, which also allows you to manage the current password, which enables you to change the password of the user.

You can also manage Multi Factor Authentication. Configuring MFA allows for an additional level of security to be applied, and this should be used for the AWS account owner, and any other users who have administrative access as a minimum. You can manage any signing certificates, and signing certificates are used for secure access to certain AWS product interfaces, and you can create new access keys for programmatic access, and it's a good practice to rotate and change your access keys periodically.

From here, you can also upload SSH public keys for AWS CodeCommit. These are used to authenticate access to AWS CodeCommit repositories, and you can also generate HTTPS Git credentials for AWS CodeCommit, and this allows you to authenticate HTTPS connections to AWS CodeCommit repositories.

Also on this screen, an access advisor shows a list of services that the user has permissions for, and the last time that those services were used with those assigned permissions. This is great to help you refine and revise the user permissions.

For those unaware of AWS CodeCommit is, it's a managed source control service that allows you to host secure and scalable private Git repositories. For more information on AWS CodeCommit, try our lab, which can be found here.

You may notice that on point four, when I mentioned permission assignments, that these can either be assigned to the user, or inherited from being a member of a group. Now, you may also remember from the previous lecture, when I explained about the security status on the IAM dashboard screen, that one of the best practices listed was use groups to assign permissions. With this in mind, and as best practice, you should consider using groups for permission assignment over assigning permission to individual users.

So let's now take a look at groups to help explain why. IAM Groups are objects much like user objects. However, they are not used in any authentication process. However, they are used to authorize access to AWS resources, through the use of AWS Policies. IAM Groups contain IAM Users, and these groups will have IAM Policies associated that will allow or explicitly deny access to AWS resources.

These policies are either AWS managed policies, that can be selected from within IAM, or customer managed policies, that are created by you, the customer. More information on IAM Policies will be discussed in a lecture devoted to this element.

Groups are normally created, that relate to a specific requirement or job role. Any users that are a member of that group inherit the permissions applied to the group. By applying permissions to the group instead of individual users, it makes it easy to modify permissions for multiple users at once. All you would need to do is modify the permissions of a group, and all users associated with the group would inherit the new access.

The alternative would be to update permissions for each and every user, which is time-intensive and prone to human error, which is why it's best practice to assign permissions to groups rather than individual users, especially in an enterprise environment. Creating a group is very simple, and is essentially a three step process.

Firstly, you give your group a meaningful name, you'll then assign permissions via policies, and finally, review your group. Once created, you can then assign users to the group.

From a limitation perspective, your AWS account has a default maximum limit of a hundred groups. To increase this, you'll need to contact AWS using the appropriate limit increase forms. Also, a user can only be associated to 10 groups, so do bear this in mind when assigning permissions.

Now we have looked at users and groups, let me now explain what an IAM role is. IAM Roles allow users and other AWS services and applications to adopt a set of temporary IAM permissions to access AWS resources.

This could be required to enforce security best practices. Firstly, let's look at an example of how the Amazon EC2 service uses an IAM role. Consider the following scenario. You have an EC2 instance running an application that requires access to Amazon S3 to Put and Get objects using the relevant API calls.

To allow access to S3, a set of credentials could be stored on the EC2 instance itself, allowing any application to use those credentials to gain access to the relevant bucket for any Put or Get API requests. However, in this scenario, you would need to manage these credentials manually, including the rotation of access keys, which is obviously an administrative burden.

To alleviate this issue, the EC2 instance could be assigned an IAM role that would contain the relevant permissions granting the EC2 instance and its applications access to S3 to perform the Put and Get API calls. This assignment can be made during the EC2 instant creation by selecting the role to be associated, or once the EC2 instance is up and running, a role could also be applied.

An existing role associated to an EC2 instance can also be replaced by a different role if required. From a security best practice perspective, you should always associate a role to an EC2 instance for accessing AWS resources over storing local credentials on the instance itself.

There are many advantages to roles, the IAM roles themselves do not have any access keys or credentials associated to them. Instead, when used, these credentials are dynamically assigned by AWS. Also, imagine you have a fleet of EC2 instances, all performing the same task, and using the same role. Now, consider that your existing application, which was used to perform Put and Get requests was now only required to perform Put requests only and Get requests must be denied.

To make the change, all you would need to do is to alter the permissions assigned to the IAM role, and all EC2 instances associated with that role would now have the correct access. If this same scenario happened by embedding credentials locally on the EC2 instance, then again, this would take a long time to replicate the change on every instance.

Let's now look at how IAM roles can be used with IAM users. There may be circumstances where you'll need to grant temporary access to AWS resources for a particular user. Instead of adopting their group permissions, or granting permissions to the individual user, which, as we know, is not best practice, we could simply allow the user to assume a role, temporarily replacing their existing permissions.

To do this, the user must first be given permission to adopt the role via an access policy. Let's take a deeper look at roles, to see how they are constructed and the different types of roles that are available.

There are currently four different types of roles that can be created, all of which serve a different purpose.

Firstly, the AWS Service Role. This role would be used by other services that would assume the role to perform specific functions based on a set of permissions associated with it. Some examples of AWS Service Role would be Amazon EC2, AWS Directory Services, and AWS Lambda, etc Once you have selected your service role, you would then need to attach a policy with the required permissions, and set a role name to complete its creation.

Secondly, the AWS Service-Linked Role. These are very specific roles that are associated to certain AWS services. They are pre-defined by AWS, and the permissions can't be altered in any way, as they are set to perform a specific function. Examples of these AWS Service-Linked Roles are Amazon Lex-Bots, and Amazon Lex-Channels. Once you have selected your service-linked role, you simply need to assign it a name and complete the creation. Remember, these roles do not allow you to modify the permissions assigned.

Thirdly, roles for Cross-Account Access. This role type offers two options. Providing access between AWS accounts that you own, and providing access between an account that you own and a third party AWS account.

This access is managed by policies that establish trusting and trusted accounts that explicitly allow a trusted principal to access specific resources. Many services use roles to allow cross-account access to resources. At a high level, these roles are configured as follows.

The trusting account is the account that has the resources that need to be accessed.

The trusted account contains the users that need to access the resources in the trusting account. A role is created in the trusting account. A trust is then established with the role by entering the AWS acount number of the trusted account. Permissions are then applied to the role via policies. And the group of users in the trusted account then need to have permissions to allow them to assume the role in the trusting account. These group of users would have a policy attached to the group, which would look something like the following, where the red text would be modified appropriately, with the relevant information.

Lastly, role for Identity Provider Access. This role type offers three different options. Grant access to web identity providers. This is used to create a trust for users using Amazon Cognito, Amazon, Facebook, Google, or any other open ID connect provider. Grant web single sign on to SAML providers. This allows access for users coming from a SAML provider, which stands for Security Assertion Markup Language. Grant API access to SAML providers.

This is similar to the previous option, but it allows access via the AWS CLI, SDKs, or API calls. For these options, a trust relationship is set up between the external identity providers to allow access to your AWS account's resources, using their existing identity provider login information. I shall be covering more on identity federation in greater depth in a lecture later in this course.

Now we have covered users, groups and roles. Let me provide a demonstration showing how each of these are created. Within the demonstration, I shall perform the following steps: 
- I will start by creating a group, 
- I will then attach permissions to this group by using an existing AWS managed IAM policy, 
- then I shall create a new user, as a part of this process, 
- I shall assign this user to the group, as per best practice.
- I shall then set up a new service role to be associated to an EC2 instance, 
- and I will then assign this role to an EC2 instance at creation.

Okay, so I'm at the home screen of the AWS Management Console, if I just type in IAM, it's the service, now I'll bring it up. And it'll take us to the dashboard.

Now, from here, to create our group, we'll need to go along to the left and select groups. Click on create new group. Give this group a name. Cloud Academy Course. Click on next step. And here, we can attach a policy to this group. So, this is where we attach a list of permissions that we want the group to have.

Let's filter this list by typing in S3, and that will just bring up all the policies that are S3 related. So, if we select this AWS Managed Policy, you can tell this is AWS Managed because it has the little AWS icon here, and any custom policies are, just blank here. But later in the course, I'll explain the difference between AWS Managed and custom managed.

But for now, let's just select the Amazon S3 full access. And you go down to next step, and that's pretty much it, so here we just need to review what, the settings we've made, so we've given it a group name and we've given it a policy as well for permissions. And then click on create group. And that's our group created, now, if you want to take a look at that, if we select it here, CA Course, and then we can see we have three tabs, user, permissions, and access advisor.

So the users tab, we can use this to add users to the group, but at the minute it doesn't have any users, and we can see up here, users in this group is zero. If we want to look at permissions, this is the policy that we applied, and then we can have a look at this policy. And it's very simple, it simply allows all actions within S3 to any resource. But we'll cover more of the policies later in the course. And then, access advisor, and this simply shows the service permissions granted to the group, and when they were last accessed.

So, what we need to do now is add some, add a user to the group.

So, let's create a new user, and for this, we go over to users. Add user, let's give it a user name, so we'll call it CA user one. And then down here, we can select the access type, and we can have programmatic access, which will give the user an access key ID and secret access key, or we can just allow them to the AWS Management Console, which will give them a password to sign in, or they can in fact have both.

For this example, I'm going to give them programmatic access and also management console access as well. So we can allow the console to auto-generate a password, or we can type in a custom password here. I'm going to leave it as auto-generated, and we can set this tick box here to ensure the user creates a new password the next time they sign in.

So next, if we go to permissions, now from here we've got a few options, we can add this user to a group directly from here, we can copy permissions from another user, or we can attach an existing policy directly to the user. Now, attaching policies directly to a user is not best practice, it's always best to add users to a group, and then attach policy to that group.

So, what we can do here, we can attach the user directly to a group. So, as that's already selected, we have the options down here of the different groups, now we created the CA Course group, so we're going to attach it to that, and as we can see, that gives him S3 full access. Click on next to review.

And now we can see the details that we've entered here, so we have the user name of CA user one, the access type, which is programmatic and console access, the password is auto-generated, and it requires a password reset, and permissions we've given them is via this group here, this CA Course, which we created just a few minutes ago. And you've created a user, and that's it.

The user has been created, and here we can have the access key ID, and also the password as well, so we can send an email directly to the user that will give them the credentials, you can also show the access key and password here as well, so you can make a note of those, if you need to.

You can also download these credentials as a CSV file, so I'll show you what that looks like. The same credentials, the username, the password and the access key et cetera. And also, a console link to allow them to sign in. So let's go back to the user, so that's created we have the credentials, let's click close, and now if we go back to our groups, click on our CA Course group, we can see that this now has one user attached.

So, this user will inherit the permissions from this group. Okay, so what we've done is we've created a group, we assigned that group permissions, using an AWS Managed Policy, we then created a user, and added that user to the group, so that user now inherits the permissions that's applied to that group.

Now, the last part of this demonstration, I just want to show you how to create a role, and we're going to create a role and assign it to an EC2 instance. So I've come across to the, the role section here. Here's a list of existing roles, click on new role. Now I want this to be an AWS Service Role, and here we have Amazon EC2, which allows EC2 instances to call aid of its services on your behalf.

So I'm going to select that role, I'm going to apply permissions, this time I want to look for RDS, and allow RDS full access. Click on next step. Give this role a name. Call this Cloud Academy RDS Full access. There's a description that you can change there, if you need to, I'm just going to leave that as default for this demonstration.

We can see our policy here, that we just added. Then click on create role. Okay, so now what we want to do is create an EC2 instance and associate that role with the instance. So, let's go across to EC2, just going to very quickly launch a new instance. So, Linux, AMI, D2 Nano, okay, cross to configure, just going to leave all that as default, and then down here, we can see we have an IAM role.

Now if we click on this drop-down list, we can see that we have two roles, this is the one that we just created just a moment ago, and then we can, review and launch, and we can see here that in our summary, if we go to our instance details, we can see that we have the IAM role there as well. And if we launch the instance, click on launch, go across to view, and again, we can see in the instance details down here, that it has that role associated.

So this EC2 instance has full access to RDS, so this EC2 instance can contact RDS and carry out any API calls relating to it. Now what I just want to quickly show you as well, recently, AWS allowed you to change the role once it was associated to an EC2 instance, before this, the only way you could attach a role to an EC2 instance was on creation, but now you can change it once it's up and running.

So, let's go across to actions, I've got the instance selected here, actions, and if we go down to instance settings, and we can say, attach/replace IAM role. And now again, we can select our role, and we have this other one here, S3 full access, simply change it there, click on apply, and then you get a message says, operation succeeded.

And we can now look down at the instance details, and we can change that the role permissions for this instance has changed, it now has S3 full access permissions. So, which means, this EC2 instance can perform any API call to S3. And that brings us to the end of this demonstration. Thank you.

We have now come to the end of this lecture. Coming up next, I will be discussing IAM policies, like the one we just attached to our group and role in the previous demonstration.