1.3 IAM: Identity and Access Management
A good access policy is crucial, whether you're just starting with AWS or running a massive amount of data processing. Identity and Access Management (IAM) allows you to meet this challenge with great success. I will show you how in this lesson.
1.Introduction3 lessons, 13:15
2.Amazon Web Services10 lessons, 1:17:39
3.Conclusion1 lesson, 01:25
1.3 IAM: Identity and Access Management
Hi, welcome back back to Explore Amazon Web Services. In this lesson we are going to look at identity and access management, short, IAM, the central point to manage your credentials and set access rights for users and services. When you access the IAM console, you can instantly see what you already set up. In my case it is the user I'm currently logged in and the group. The first important thing to note is that you have a separate sign in link that is specific to your account. Normally, it is set to your account number, but you can rename it to make it more memorizable. On the top right you can see I´m currently signed in as mmuehlberger@mmuehlberger, which is the account name. Now let´s visit the link to see what is different from the traditional form. You can see that the account name is an essential part of the login. User names are only unique per account. You can also see that there isn't a way to reset the password. This has to be done by an administrator inside the console. Let's go through the different features of IAM. I'm going to start with groups because they are the simple. You give the group a name, And attach some policies to it. We will look at them in detail in a minute, but policies are the rules that restrict access to services. The first policy you see right away is the AdministratorAccess policy. It is a convenient way to give a user approved access to almost everything in the console. When you want to give someone complete access to a service, there are four access policies for each of them. There is also a convenient read-only policy when you want to give, for instance, to serve as a role, only consumer status. I'm just quickly going to add all the services we are going to use in this course to our tutsplus group. When you are done you can review all the services by their under some resource name, short r, before you actually create the group. Users are a bit more complicated. You can add them in bulk, if you like, and you will get security credentials for everyone in a CSV file. Those are your AWS access key ID and your AWS secret access key. They work a bit like username and password, but are randomly generated. You will have to keep this file secure, as you won't be able to retrieve the key if you lose it. You will have to create new credentials. After you create a user, you can look at its details. After generation, there is no password, which means the user won´t be able to log in to the console. It will only be able to use services through the credentials. You can also add the user to a group, or attach pre-made policies. You can also attach inline policies very specific to a single user. Further down, you see the credentials. Each of them can be deactivated or deleted. You can also create new ones, which can be used side-by-side. There are also options to create the login password, set up multi-factor authentication, or signing certificates, for instance, for mobile app signing. Next on to roles. Roles are used to restrict access between services. They are somehow like users, if you see a service or even a specific instance of the service as a user, but about as simple as groups. You can set up roles for services, cross account access, yes, you can access resources of a different account, if you have the rights to do so only for identity providers. The first option though is the most common. Next, you again attach some policies to the role. Next up, our policies. When you look at the policy, it is essentially a JSON dictionary that allows or denies access to a specific resource that is described by its ARN and accompanying action. To create a new policy you have the option to copy and edit an existing one, use a policy generator, or copy and paste your own. We are going to use the second option since it has a nice interface to guide us through the process. We want to make a kind of accountant policy, so we want to give access to the account data, user information, and billing sections. After generating the policy we can choose a name, and review the generated JSON dictionary. We can now search for the accountant policy in its long list of Amazon created policies. Now on to identity providers. Those are used if you already have a user management outside of AWS, and want to give your users access to services without creating new accounts for them. You can use XAML or OpenID as an interface for that. The last important section is the account settings. Here you can set your password policies that are enforced on your users. There is also a section for creating credential reports and specific keys for encrypting your data and storing it with AWS, like on S3, EBS or Redshift. Now, you know your way around the security help, and give your users and services exactly what they need, but not more. In the next lesson, we're going to look at our first real service, EC2. See you there.