Unlocking Dynamic Secrets with AWS STS Tokens
A Deep Dive into Securing Temporary Access for Scalable, Secure Applications
Introduction
With the cloud-native landscape, managing the credentials securely turns out to be a problem for most of the organizations involved. Balancing security, flexibility, and cost-efficiency generally does not result in a solution that fits everyone. There's a debate where some believe to use dedicated tools like Key Vault, while others believe that intricate encryption strategies work best, although the correct path is never quite clear.
🔐 Worried about credential theft, compromise, or hacking?
🔐 Struggling to integrate traditional secrets managers seamlessly?
🔐 Wondering how much security is enough for your data?
🔐 Tired of the pains of manual encryption and secret management?
🔐 Struggling with the headaches of key rotation and cumbersome redistribution?
🔐 Isn’t it challenging to balance simplicity, cost-effectiveness, and product security?
……… hundreds of problems.
To solve these challenges, AWS offers an optimum solution by Security Token Service known as STS. STS allows the creation of temporary, dynamic credentials specific to certain tasks and timeframes. This has the effect of reducing risk from unauthorized access but also strengthens overall security.
In this post, we will take a deep dive into how using STS tokens to generate dynamic secrets in AWS can significantly strengthen your cloud security strategy while offering a scalable and flexible way to manage access with ease.
Before we dive deep into STS credentials, lets briefly understand how Authentication works in AWS ?
Authentication in AWS is the backbone of secure access to cloud resources. Imagine wearing a “Caller IAM Role” hard hat This is your identity in AWS. Whether you’re navigating the AWS Management Console, using the CLI, or leveraging powerful AWS SDKs, this role enables you to interact with AWS services. Wait, there is magic here, when you make an API request, your identity doesn’t just walk in unannounced. It comes armed with a secret key, signing every request. This signature is like a hotel room card, ensuring only authenticated entities can access AWS services, such as storing data in S3 buckets.
This handshake between IAM roles, other tools, and API requests is the main pillar of the security model in AWS. When dynamic secrets like AWS STS tokens come into play, the game gets even more thrilling. Lets get onto the roller coaster to unlock secure, time-bound access to AWS resources !!!
Traditional Way of creating Credentials in AWS
I am pretty sure you all have downloaded the above credential.csv file. Unknowingly, heres where you give out the opportunity for intruders, such credentials are Static Credentials that are pre-defined and do not change unless changed explicitly modified by an administrator or authorized user. For example, database passwords, or encryption keys which are constant over time except as purposefully rotated. But today, we are going to go one extra mile to keep away from ransoms. Let's dive deep into Dynamic Secrets.
Introducing short lived token-based authentication
The name itself states "dynamic means changing" ie: they have short term validity.
In technical speak, they are issued on demand and automatically invalidates after a defined time period known as expiration time.
Once these tokens expire, AWS no longer considers the tokens valid and automatically revokes all types of access from the API requests made with these.
You can generate these tokens using AWS Security Token Service (STS)
While creating the tokens, you may specify the validity duration : : how long the STS is good for.
Because they are short lived so they will have perks in improving security of applications like you won’t need to update them or explicitly expire them when they are no longer needed. No pain of the manual key rotation. After it expires, the credentials cannot be reused. You may specify how many days the issued credentials are valid for. You entirely own the token from controlling the expiration to revocation. That's the real beauty!!! Let us understand it better with a use case.
Use Case: Granting Temporary Access to AWS Production Resources Using Cross-Account Roles
In most organizations, AWS environments are separated into different accounts for better security and management like Development (Dev) and Production (Prod) accounts. In this use case, Alice, a developer in the Dev account and she needs temporary access to upload files to an S3 bucket in the Prod account. Alice will make use of the AWS Security Token Service to adopt a role within the Prod account while allowing her access to temporary credentials with least privilege.
Solution: Cross-Account Role using AWS STS
Step 1 : Create a Role in the Prod Account
Create an IAM role within the Prod account that provides permissions only to access S3.
The role needs to have an attached policy with the permissions Alice has to upload files to an S3 bucket.{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": ["s3:PutObject","s3:PutObjectAcl"],"Resource": "arn:aws:s3:::prod-bucket/*"}]}Define the Trust Policy to allow only the user Alice belonging to the account Dev to be able to assume this role.
{
"Version": "2012-10-17",
"Statement": [{"Effect": "Allow","Principal": {"AWS": "arn:aws:iam::<DEV_ACCOUNT_ID>:user/Alice"},"Action": "sts:AssumeRole"}]}
Step 2: Attach AssumeRole Permissions to Alice’s User (Dev Account)
Attach to the IAM user of Alice on the Dev account a policy granting her the possibility to call action sts:AssumeRole with Prod account{"Version": "2012-10-17","Statement": [{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::<PROD_ACCOUNT_ID>:role/DevToProd-S3-Access-Role"
}]}
Step 3: Assume the Role Using AWS STS
After having set up the role and permissions, Alice could use AWS STS to assume a role in the Prod account to get temporary credentials
Example CLI Command to Assume the Role:aws sts assume-role --role-arn arn:aws:iam::<PROD_ACCOUNT_ID>:role/DevToProd-S3-Access-Role --role-session-name AliceS3Access --duration-seconds 3600
Sample Output : It returns temporary credentials: AccessKeyId, SessionToken, expiration (1 hr :3600 secs).
Step 4: Use Temporary Credentials to Access S3
Once Alice has obtained the temporary credentials, she will be able to use them to access the S3 bucket in the Prod account.aws s3 cp myfile.txt s3://prod-bucket/myfile.txt --access-key <AccessKeyId>--session-token <SessionToken>
Advantages of Using AWS STS Credentials
AWS STS Credentials are valid for a specified time interval only. (for example, 1 hour) This makes unauthorized access less likely ensuring robust security.
The least privilege access that is given grants the least required permission, which reduces access to a specific resource; for example : only S3 in the Prod account.
Short-lived tokens minimize the window of opportunity for attackers to use stolen credentials thereby improving overall security.
AWS STS services give users temporary, secure cross-account access and does not require the creation of long-lived IAM users or credentials to prevent proper isolation between accounts.
Other Usage of AWS STS in Real Life Applications
Microservice Communication : In Microservices architecture where a AWS Service lets say Service A needs to call an Api exposed by another AWS Service B. Rather than Hardcoding the static creds, Service A can leverage use of STS and Service B can use it. This allows better authentication and API authorization request, enhancing security in wider sense.
Cross Account Access : An organization has several AWS accounts, and a user in AWS Account A needs to access resources in AWS Account B. The user can be granted roles and cross account access to allow use of resources in another AWS account. This process is referred as Delegation Approach to temporary access. (The Alice scenario exactly fits in here)
Temporary Access for External Partners : In those applications where the company is teaming up with a 3rd party vendor who requires temporary access to the AWS resources, such as AWS S3 to perform a data backup and restore. For such use case instead of providing long lived static access keys and secret keys of AWS IAM creds, the company may avail the usage of STS and reduce the employment of short lived creds for the course of the project-this will ensure security in a holistic sense.
User Access in Application : A web application must make it possible to upload files directly to S3. Rather than relying on service accounts with extremely broad permissions, the application creates short-lived access tokens for all users based upon their roles in the application to be used at S3 that are only provisioned for just a short while to upload one file.
Conclusion :
This approach using AWS STS and IAM roles allows for secure, temporary cross-account access while maintaining strong security practices, such as least privilege and temporary credentials.We mitigate risks of unauthorized access and reduce an attack surface because short-lived tokens will be used. This pattern fits best for securing the granting of developers or users in general some specific access on resources across AWS accounts.
References:
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html
https://docs.aws.amazon.com/code-library/latest/ug/python_3_sts_code_examples.html
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_sts-comparison.html
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html
https://vox.veritas.com/discussions/netbackup/when-it-comes-to-secrets-how-secure-is-your-application/903848#M253965