If you would like to read the other parts in this article series please go to:
- Secure services and resources with AWS Identity and Access Management (Part 2)
- Secure services and resources with AWS Identity and Access Management (Part 3)
- Secure services and resources with AWS Identity and Access Management (Part 4)
- Secure services and resources with AWS Identity and Access Management (Part 5)
Introduction
Security has long been the cloud’s not-so-silver lining and a top concern of organizations as they first consider moving applications and/or data to the cloud. Cloud providers are well aware of this and have moved to add security features that give customers more control over securing their assets in a cloud-based environment. If your organization has chosen Amazon Web Services as its cloud provider, you have several options for making your resources more secure.
We have previously discussed the use of AWS Directory Service, which you can use to connect your AWS resources to your on-premises Microsoft Active Directory network in a hybrid cloud scenario. In this multi-part article, we’re going to look at how to use AWS Identity and Access Management (IAM) to create and manage users and groups and assign permissions to them so as to granularly control how they can access your AWS resources.
How IAM works
AIM is an identity and access management feature that supports several different types of authentication, including passwords, access keys, and multi-factor authentication through AWS MFA. You create user accounts in IAM and then assign security credentials to them depending on the type of authentication you want to use. Users can be designated either as regular users or administrators, and you can also create systems accounts for granting access programmatically.
IAM users and groups
After you have created an account for the user and assigned the security credentials to that account, then you can add the user to groups. A user can be a member of more than one group (up to ten). Using groups in IAM, like using groups in Active Directory, makes it easier to manage user permissions because you will likely have a number of different users who will need to have the same permissions to resources.
This simplifies the process and reduces administrative overhead since you don’t have to assign each permission to each user individually. Instead, you just create a group that has the appropriate permissions and then put all of the users who need those permissions into that group. Later, if you need to make a change that will affect all of the members of the group, you only have to make that change once rather than doing it over and over for each member of the group.
You can create new IAM users and groups via the management console or you can do it through the command line interface. You would use the create-group command first to create a group, and then place a new user into it by creating the user account with the create-user command and the add-user-to-group command.
User authentication and credentials
You have a number of options when it comes to user authentication and credential types, depending on what type of AWS resources you want the user to access. In general, passwords are used for logging onto the management console and other secure pages on the AWS web site. If users need to make secure REST or Query protocol requests to an API for an AWS service, they will need to use access keys. CloudFront uses key pairs for authentication.
By default, new IAM accounts don’t have passwords or access keys, and they don’t have any permissions assigned so they can’t access any AWS resources or do anything in AWS. You will need to assign permissions to users, either individually or by placing each user into one or more groups. Once users have been assigned permissions (for example, to access data stored in S3 or to run EC2 instances), all of the billable activities that are performed by any of those users will be billed to the AWS root account. For this reason, you’ll want to be careful about which permissions you grant and only give each user the least privilege needed to do his/her work.
Note that the default limit on the number of IAM user accounts you can have belonging to one AWS account is five thousand, and you are limited to one hundred IAM groups per AWS account. You can, however, assign temporary credentials to additional users if you need to.
Temporary credentials are issued via the AWS security token service. This gives you a way to allow users to access AWS resources without having AWS identities created for them. Note that the temporary credentials, as the name implies, only last for a specific period of time. You can set the expiration time, between fifteen minutes and thirty-six hours; the default is twelve hours.
AWS user name and password vs. IAM user name and password
If you are the admin who signed up for an AWS account, you will have an AWS user name and password that you signed up with. Your user name is your email address. You can sign into the management console and other secure AWS web pages with those credentials. However, these are root level credentials, and just as it’s always recommended that you not use the built-in admin account for daily logging in to a computer, Amazon recommends that you not use the root level user account for signing into AWS web pages.
Root account credentials have access to everything in the AWS account. You can’t limit the permissions on the root account. All other accounts operate with user credentials. It is a best practice to create an IAM user account for administrators (including yourself) and grant those accounts full access. The admin can then use those credentials, instead of the root credentials, for signing into AWS resources. The advantage here is that you have control over these types of admin accounts and you can limit or revoke their privileges if you need to in the future.
You might need to give more than one person administrative access, which includes being able to sign into the management console. You certainly don’t want to allow everybody to use the same (root) account to do this, as there would be no way of tracking who did what and no way to revoke admin privileges. In this case, it is imperative that you create separate IAM user accounts and that way each of the admins will have his/her own individual user name and password for signing into the administrative tools.
Access key ID and secret access keys
An access key is made up of two parts: the access key ID and the secret access key, which is a string of characters. Access keys are necessary for making programmatic requests to AWS services; you use the key to sign the request. You can do the signing with the AWS SDK or you can do it manually. The digital signature verifies the identity of the person who is making the request.
You don’t have to sign requests that are made using an AWS SDK or the AWS command line interface. The tools sign the requests that they create and send for you, but you do have to provide the tool with the key. When you send HTTP or HTTPS requests to AWS programmatically, you need to include signing code. Requests should be sent over SSL/TLS (HTTPS) so that the request and response will be encrypted and protected from unauthorized viewing while it’s in transit.
Multi-factor authentication
We all know that user names and passwords don’t provide the most secure means of authentication; security experts have been declaring the “death of the password” for many years now. Although it is taking much longer than expected, many organizations are finally transitioning to multi-factor authentication methods – smart cards or tokens, fingerprints or other biometric identifiers, or most recently the use of a mobile device as the second factor.
This latter scenario makes sense because most people already have their smart phones with them all the time, so it doesn’t require that you carry around something extra and it’s less invasive than biometrics. AWS MFA can use either a dedicated hardware device (key fob or card) or you can install a time-based one-time password (TOTP) application on your smart phone to turn it into a virtual MFA device.
You will need to configure the app to work with AWS and then enable it. The app has to be one that generates six-digit authentication codes.There are different apps that will function this way, and many of them make it possible to host multiple virtual MFA devices, but you can have only one MFA device set up per IAM user account. Virtual MFA apps are available for Android, iOS and Windows Phone.
New virtual MFA devices can be provisioned via the command line (using the iam-vritualmfadevicecreate command), by using the CreateVirtualMFADevice API, or via the IAM console (both for IAM users and for the AWS user account). Note that if you enable AWS MFA for an IAM user, that user must always use the device to sign in to any AWS web site. To disable MFA for the account, you must contact Amazon.
IAM policies
You can assign an IAM policy to an IAM user account via the IAM console or the command line. The IAM console includes policy templates for common situations, such as the Power User template. To assign policies via the CLI, the policy needs to be saved to a file and then you use the put-user-policy command to assign it to a user. We will delve more deeply into IAM policies in part 2 of this article.
Summary
In Part 1 of this article, we provided an overview of what AWS Identity and Access Management (IAM) is and how it works, particularly in regard to users and groups and the authentication methods that are supported. In Part 2, we’ll go further into the particulars of IAM policies, permissions, and roles, as well as how to integrate IAM into a federated environment.
If you would like to read the other parts in this article series please go to:
- Secure services and resources with AWS Identity and Access Management (Part 2)
- Secure services and resources with AWS Identity and Access Management (Part 3)
- Secure services and resources with AWS Identity and Access Management (Part 4)
- Secure services and resources with AWS Identity and Access Management (Part 5)
