What is a traditional way of getting AWS STS (Security Token Services) tokens by any DevSecOps team?
Yes, you guessed it right? #AWS CLI. This is the most preferred way by any DevSecOps team and by far the common way.
After building enterprise level #Serverless applications, you would have probably noticed that most demanding AWS service is the STS service from AWS. Applications (internal or external), developers, ops team, security team; they all are generating these sts tokens at some point of time. You would want to get STS credentials using least privileges you can set and just to get your work done in that context.
Why this is important?
Cloud adoption is big time high and this is really important from security perspective. Whatever application you are building in the cloud, security should be your first priority.
The AWS Security Token Service (STS) is a web service that enables you to request temporary, limited-privilege credentials for AWS Identity and Access Management (IAM) users or for users that you authenticate (federated users). This guide provides descriptions of the STS API.
STS tokens are being used by IT teams across the world working on AWS platform and we don’t remember AWS STS CLI commands every time.
Wouldn’t it be great, if you just have to enter total number of duration for which you are looking to generate STS token and you get these STS tokens.
Wouldn’t it be great, if you can access this STS interface anytime you or your team members need? This is really interesting and helpful within your team and the whole company.
So, how it looks like?
As you can see in the above picture; you generate an STS token just by duration (and your secret. Explanation later). For cross account, you simply specify few more information (ROLE ARN, ROLE SESSIONAME, EXTERNAL ID) and you get STS tokens for cross aws accounts. From automation perspective, you can get rid of ROLE SESSIONNAME and EXTERNAL ID too.
So, what’s going on in here?
There is no magic at all. It is just automating the whole process anyone does to get the STS credentials. Let’s say this app is called STSGen. Frontend (in this case an Angular app) calls an AWS API endpoint, API further calls an AWS #Lambda function; passes necessary information and gets STS credentials in return. Below flow diagram explains this at a high level.
Are you asking me to build an app?
Nah!!! That is certainly not the case. Doh! All the necessary works have been done and open sourced. So it is just ready to be consumed.
Show me how?
This is a serverless app and uses serverless framework ((https://serverless.com/)) to automate everything. Guys/team using AWS SAM (Serverless Application Model) must be knowing this framework or might have used it previously.
Lambda is using Node.JS as a programming language (backend and which is getting sts tokens for us) and frontend is in #Angular. There are steps that you need to follow to deploy this app to able to get sts tokens generated. Let’s follow them in the order they have been provided further down.
git clone this app from https://github.com/sketchmycloud/awsstsapp.git
Once cloned the app, open the folder in Visual Code or any other editor of your choice. Make sure you have serverless framework installed (https://serverless.com/framework/docs/getting-started/) alongwith Node.JS.
Go to /serverless/serverless.yml file and you should see below code
region: eu-west-1 #your region
lambdaRole: #your role against you want to get the credentials for
unLockKey: #anysecret key e.g. 135247
Choose your “region”, “role” (should be able to execute lambda role, so make sure a role has basic lambda execution role) and an unLockKey. unLockKey could be any random digits and works as a password to send it to lambda to generate STS tokens locally. This is also to make sure, no once can access this app locally, unless they have access to this unLockKey. (Please bear in mind that anyone can get access to your IAM security tokens, if they have access to your local machine)
At this moment, you are ready to deploy your serverless code. Make sure, you have configured; aws credentials locally against your AWS account, where you are looking to host your code.
Go to https://serverless.com/framework/docs/providers/aws/guide/credentials/ for more detals to set-up aws credentials.
If everything goes fine, you should have an API endpoint and other details. Please preserve this API endpoint.
Now go to /webapp/src/app/sts.service.ts file. You should have a variable called _apiURL
const _apiURL = "";
Replace this URL with the API endpoint, you have from step 5.
Go to your app directory /webapp/ and run npm install. This installs all the necessary Angular and Node.JS dependencies for the front end.
When installation is completed, run npm start
This makes the web interface available at port 4200 (you can change this port).
Once app has compiled, please go to http://localhost:4200 to view the front end app (below).
On the page, you can generate STS credentials against the AWS account, where Lambda is running or cross account; provided you have setup cross-account already. Checkout https://aws.amazon.com/blogs/security/how-to-enable-cross-account-access-to-the-aws-management-console/. You can generate STS token for 12 hours, however AWS does not allow role chaining and hence cross account STS tokens are limited to 1 hour only. Checkout https://github.com/coinbase/assume-role/issues/24
Developers, SysOps, Administratots can use this app locally and generate STS tokens, whenever they need without going through whole CLI.
Since frontend is in Angular, you can build the project and host the frontend app via S3 and use it online. Public access is strictly no no. You might want to limit the access to you by applying SECURITY GROUPS and necessary policies or considering white-listing IPs via S3 bucket policy.
Going beyond this app
Enterprises want to see all these incoming requests and who is accessing things. In this particular case, you can enable CloudTrail to send your access logs to S3 bucket. S3, because it is an inexpensive way to store your data. You can go further down to central logging architecture and send all these logs from other regions to the same S3 bucket.
Given below architecture explains this further.
At some point of time, you would want to analyze and visualize your data. Since you are collecting all these data in your S3 bucket. You can simply use AWS Athena to analyze your data right away. There is a nice write-up on to Turn your AWS S3 data into insights you always wanted.
There are whole a lot of things you can think to build more features on the top of this app and is left with your curiosity.
Developers might want to create different features on the top of this app to be consumed internally or externally and would be really nice to know, what and how you are using this app beyond.
Please contact me at email@example.com for any issues or challenges and I am happy to help.