The use of permanent credentials is an extremely common practice with AWS. Injecting the values of AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY into environment variables is a simple and reassuring solution for most developers. However, from a security standpoint, this practice is far from ideal. Over time, these sensitive values can leak, and it becomes difficult to control how they are used.

The good news is that there are better alternatives! We’ll start by discussing how to block their creation, and then explain the replacement solutions for the following three areas: developer access, AWS services, and DevOps pipelines.

Restricting Usage

Before even discussing alternatives to permanent credentials, it’s essential to restrict their usage. To do so, the best approach is to use an SCP (Service Control Policy). An SCP is an IAM policy that can be applied to all AWS accounts within an organization.

Although short, this policy is extremely powerful! It blocks the creation of long-term credentials and IAM users. The strength of an SCP lies in the fact that even a root user cannot override it, thus ensuring compliance across all Thirdbridge projects.

Managing Developer Access

The first challenge to address is managing developer access. Typically, an IAM user is created for each developer. That user can then generate permanent credentials to, for example, run a project locally. The recommended alternative for this use case is to use IAM Identity Center along with AWS Organizations.

AWS offers the concept of an Organization. Simply put, an Organization is a collection of separate AWS accounts that can be grouped into Organizational Units (OUs). At Thirdbridge, each client project is represented by an OU. Each OU contains two AWS accounts: one for lower environments (dev, uat, staging, etc.) and one for production.

The strength of IAM Identity Center lies in its ability to create a single profile for each developer and assign the necessary permissions based on their role and current responsibilities.

So, even if a developer works on 10 different projects, they have only one account. When logging into the AWS web console, they do so through a role managed by IAM Identity Center. Finally, if a developer needs an AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY to run a project locally, IAM Identity Center can provide temporary credentials that can be used.

Running an AWS Service

A common mistake is manually injecting AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY into an AWS service. In reality, AWS services all have an IAM role associated with their execution. Whether it’s ECS, Lambda, or EC2, you should always use the role assigned to the service rather than injecting credentials.

Continuous Deployment

Removing permanent credentials from continuous deployment pipelines is often the most intimidating part for developers. Injecting AWS keys via the secrets management systems offered by DevOps platforms like GitLab and GitHub is an extremely common practice.

However, the recommended approach is to use the OIDC protocol to establish a trust relationship between the DevOps platform and AWS. This not only removes the need for permanent credentials, but also enables much more precise permission scoping. For example, you can assign an IAM role to a specific Git branch, thereby respecting the principle of least privilege.

Since setup can sometimes be a barrier to adopting OIDC, we’ve prepared a detailed step-by-step guide for both GitHub and GitLab.

🔗 Gitlab OIDC

🔗 GitHub OIDC

Conclusion

Restricting the use of permanent credentials in AWS is an essential security practice for any organization aiming for a high level of compliance. While limiting their usage with an SCP is relatively easy to implement, setting up their alternatives can sometimes be more complex.

We hope this short guide will be helpful to other organizations looking to elevate their operational practices with AWS. We’ve kept things high-level to keep it light to read, but feel free to reach out to us for any more specific questions 🙂