One of the largest security concerns in AWS is managing identity & access management (IAM) access keys. IAM keys are used to access the AWS API with the same privileges as the connected IAM user. They can be used to provision, de-provision, and manage resources. In some AWS services, IAM keys are used to read and write data through the AWS API. These are the keys to your AWS cloud.
While there are many best practices published for limiting the permissions of keys and policies for storage and rotation of keys, the easiest way to manage keys is simply to have no keys to manage.
The diagram below displays an architecture that removes the need for creating IAM access keys for users, applications, and third-party AWS accounts:
The best way to avoid creating keys for users is to skip creating IAM accounts. In this architecture, we use a Security Assertion Markup Language (SAML) integration from an existing corporate directory (ADFS) or SaaS directory service (Okta, Onelogin, etc.). These services focus on managing access to the AWS console, but can also be used for temporary key generation. Most of them offer a script that will authenticate the user and obtain keys. Once SAML is configured, keys can be generated using the method described in this ADFS example.
This creates a temporary key-pair, which will expire in one hour. One hour is plenty of time for most ad-hoc automation and command line interface (CLI) requests. Engineers are still allowed to access the Amazon Web Services (AWS) application program interface (API) from their workstations, but do not have to worry about complying with key rotation policies. This also reduces the usefulness of keys that may accidentally be stored in code or shared in an insecure manner.
Use instance roles in AWS for application access to the AWS API. All modern versions of the AWS software development kits (SDKs) and CLIs support the use of roles when running in AWS. There should be no excuse for generating keys for applications that run inside AWS. Also, consider using an EC2 instance to run infrastructure automation. AWS CLI, Terraform, Packer, any tools that need access to the AWS API could be run from an EC2 instance to avoid creating keys.
Keys are commonly created for integration with third-party tools and services requiring access to the AWS API. Many of these services actually run in AWS, as well, and are beginning to offer cross-account roles as an option for customers to allow access. Cross-account roles give you the ability to grant access to a role within your AWS account to a separate AWS account. This can either be another AWS account that you own or a third-party AWS account.
In this architecture, creating IAM Access Keys should be the exception, not the default. However, there may still be a few reasons to create IAM keys:
- Third-party tools that need access to the AWS API, but do not support cross-account roles or run in AWS
- On-premise applications that are integrating with AWS services
- Migration tools that run in the datacenter
In these cases, keys will need to be created and should follow best practices for granting the least privileges required.