Using IAM Role Anywhere Credentials for Seamless Access Beyond AWS
Amazon Web Services (AWS) Identity and Access Management (IAM) Roles are temporary and provide access keys that expire automatically. This enhances security by reducing the need for long-term credentials.
Whilst IAM Roles are a powerful tool for managing access to AWS resources did you know that they can also be directly used outside of the AWS ecosystem without the need for any IAM user accounts defined for programmatic access only?
This is achieved by using the IAM Roles Anywhere approach. This feature was announced a while back but I figured a refresher might be helpful so hence the blog 🙂
“With IAM Roles Anywhere you now have the ability to use temporary credentials on AWS, eliminating the need to manage long term credentials for workloads running outside of AWS, which can help improve your security posture. Using IAM Roles Anywhere can reduce support costs and operational complexity through using the same access controls, deployment pipelines, and testing processes across all of your workloads. You can get started by establishing the trust between your AWS environment and your public key infrastructure (PKI). You do this by creating a trust anchor where you either reference your AWS Certificate Manager Private Certificate Authority (ACM Private CA) or register your own certificate authorities (CAs) with IAM Roles Anywhere. By adding one or more roles to a profile and enabling IAM Roles Anywhere to assume these roles, your applications can now use the client certificate issued by your CAs to make secure requests to AWS and get temporary credentials to access the AWS environment.”
The https://docs.aws.amazon.com/rolesanywhere/latest/userguide/getting-started.html guide talks to how to set things up.
Essentially, you register the CA with IAM Roles Anywhere as a trust anchor to establish trust between your public-key infrastructure (PKI) and IAM Roles Anywhere. Pretty nifty huh. You can also use AWS Private Certificate Authority (AWS Private CA) to create a Certificate Authority and then use that to establish trust with IAM Roles Anywhere if you’re using this service already.
For IAM Roles Anywhere to work, you need to create a profile to specify which role IAM Roles Anywhere can assume. This profile also specifies what your workloads can do with the temporary credentials as you can define IAM session policies, which can be managed or inline, to limit the permissions created for a session.
To use temporary security credentials with AWS SDKs and the AWS CLI, you can use two methods:
From the documentation:
“To successfully authenticate, the following constraints must be satisfied:
- The signature attached to the request MUST be validated against the signing certificate (also attached to the request).
- The signing certificate MUST have a valid trust chain to a Certificate Authority (CA) certificate configured in the customer account.
- The target role for which credentials are issued MUST have an
AssumeRolePolicyDocumentthat allows IAM Roles Anywhere service principal,rolesanywhere.amazonaws.com, to callsts:AssumeRole,sts:TagSession, andsts:SetSourceIdentity. For more information, see Granting permissions to pass a role to a service in the IAM User Guide. - The target role for which credentials are issued MAY have additional
Conditionpredicates in theAssumeRolePolicyDocumentthat restrict authorization based on attributes extracted from the X.509 Certificate (for example, Subject or Issuer).“
CreateSession API
1. Authentication with X.509 Certificates
To begin the process, the client or entity (e.g., an application or user) sends an authentication request to the CreateSession API. This request is typically authenticated using X.509 certificates. X.509 certificates are a widely-used standard for secure communication and authentication on the internet.
2. Signature Authentication
The CreateSession API authenticates incoming requests by verifying the signature associated with the X.509 certificate used for authentication. This signature helps ensure the authenticity and integrity of the request. If the signature is valid, the request is accepted, and the API proceeds with the next steps.
3. Exchange for Session Credential
The CreateSession API operates similarly to the AssumeRole operation in AWS IAM. It exchanges the authenticated request, which includes the client’s identity and potentially additional information, for a standard SigV4-compatible session credential.
4. SigV4-Compatible Session Credential
The session credential obtained from the CreateSession API is in a SigV4-compatible format. SigV4 (Signature Version 4) is the AWS authentication method used for HTTP requests to AWS services.
These session credentials include an access key, secret key, session token, and expiration time, making them compatible with AWS services and external systems that support SigV4 authentication.
Credential Helper Tool
To use the credential helper tool from the CLI, you need to download the binaries and then use the following command:
$ ./aws_signing_helper credential-process \
--certificate /path/to/certificate \
--private-key /path/to/private-key \
--trust-anchor-arn arn:aws:rolesanywhere:region:account:trust-anchor/TA_ID \
--profile-arn arn:aws:rolesanywhere:region:account:profile/PROFILE_ID \
--role-arn arn:aws:iam::account:role/role-name-with-pathNote: To use temporary security credentials with AWS SDKs and the AWS CLI, you can configure the credential helper tool as a credential process. For more information, see Sourcing credentials with an external process.
As you can see, IAM Role Anywhere credentials provide a secure and convenient way to access resources outside of the AWS ecosystem while maintaining the benefits of IAM security. By following the code examples provided by AWS, you can seamlessly integrate AWS IAM Role credentials into your applications or scripts to access external services or resources with ease whilst enhancing your security posture.
Hope this helps! 🙂
