3. DETAILS
● 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.
4. ● 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.
5. ● 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 or programmatic access, and the console login link, etc.
These details can also be emailed to the new user, using the send email link.
6. ● 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.
7. ● 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.
8. ● 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.
9. ● 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.
10. ● 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.
11. ● 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.
12. ● 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.
13. 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.
14. 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.
15. 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.
16. 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.
17. 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 account number of the
trusted account.
18. 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
19. 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.
20. 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.
21. 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.
22. 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
23. 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.
