The 4 Golden Tenants to avoid long-lived credentials within AWS
Are you concerned about the security of your AWS credentials? As more and more businesses move their operations to the cloud, keeping your sensitive information safe has never been more important. Unfortunately, many people make simple mistakes that can leave their AWS credentials vulnerable to attack. In this article, we will explore the 4 golden tenants that will help you avoid long-lived credentials and keep your AWS account secure. By following these essential tips, you can ensure that your sensitive data remains protected and your business stays safe from harm. So let’s dive in and learn how to safeguard your AWS credentials like a pro!
- Common Identity for all user access
When I refer to user access, I’m generally referring to humans here. To avoid long-lived credentials then all access into the environment should adhere to the following:
- Tied to a corporate identity — This generally means using single sign on (SSO) and accessed using federation from the corporate identity. This means that the user account is inherently connected to the companies onboarding and offboarding processes.
- Using Multifactor Authentication — Whilst password authentication is great as a starting point; it means that you’re using persistent and long-lived credentail. Coupling password authentication against a second authentication mechanism can establish a short-lived credential. This should be either a one-time password or a token which frequently changes (eg, an RSA token).
What about CLI sessions?
Commonly people will create aws credentials files container access keys and secret ids — this is effectively a long-lived credentail which should be avoided.
There are a few good guides around how MFA should be used with CLI access to:
- https://aws.amazon.com/premiumsupport/knowledge-center/authenticate-mfa-cli/
- https://stackoverflow.com/questions/34795780/how-to-use-mfa-with-aws-cli
IAM Roles for EC2 instances and other AWS Services
Using IAM roles for EC2 instances and other AWS services is a critical security measure that can help you manage access to your resources more effectively. IAM roles provide temporary credentials that are automatically rotated, making it easier to manage access permissions and ensuring that your resources remain secure. By using IAM roles, you can avoid the need to store and manage long-term access keys on your EC2 instances, which can be a security risk. Instead, you can assign permissions to the role, and any instance or service that assumes that role can access the resources it needs without the need for a static access key. This not only simplifies management but also ensures that you have better control over who can access your resources, and you can easily revoke access if needed. Overall, using IAM roles is a best practice that can help you enhance your AWS security posture, reduce risk, and make management more streamlined
More details around how to have this deployed are at:
OpenID Connect for CI/CD and other automated processes
Using OpenID to integrate CI/CD pipelines with AWS provides several benefits for managing access and security in your continuous delivery process. OpenID is an open standard for identity and access management that provides a secure and efficient way to authenticate and authorize users. By integrating OpenID with your CI/CD pipelines on AWS, you can simplify the management of user credentials and access to AWS resources, while also improving security and compliance.
There are several examples of how to integrate OpenID with CI/CD pipelines on AWS, including using AWS CodePipeline, a fully managed continuous delivery service, with OpenID Connect. With this integration, you can authenticate users and control access to CodePipeline actions using your OpenID provider’s identity and access management system. You can also use OpenID to integrate with other AWS services, such as AWS CodeCommit and AWS CodeBuild, to manage user authentication and authorization.
There are also other examples around how you can integrate with various third parties. Some examples of this could include:
Third Party Access via AWS Role Assumption coupled with an External ID
When it comes to managing access to resources in cloud computing environments, Identity and Access Management (IAM) is a crucial tool. However, many organizations rely on third-party services to access and manage cloud resources, which can complicate IAM management. One approach to this challenge is to use external IDs to assume IAM roles from third-party accounts. An external ID is a unique identifier that can be used to establish trust between the two accounts. By using an external ID, the third-party service can only assume the IAM role when it presents a valid ID, helping to ensure that only authorized parties can access the resources. This approach provides a secure and straightforward way to manage IAM roles when third-party services are involved, reducing the risk of unauthorized access or data breaches. Overall, using external IDs to assume IAM roles from third parties is an essential practice for any organization using cloud computing services.
Details around how this can be configured is at:
Before you go — if you’ve got this far you’ve hopefully seen some value in this article. I write and publish this content free of charge. The cost for reading it though? Please like the article and click follow me — Think of this as a gentlemen’s agreement. The cost is nothing finacial just a token of appreciation for the time taken to put this together. Thank you
