AWS Developer Credentials Sent Straight to an AWS Secret
ACM.444 Creating credentials without ever exposing them to users or in code
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⚙️ Part of my series on Automating Cybersecurity Metrics. The Code.
🔒 Related Stories: AWS Security | Application Security | Batch Jobs
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In the last post I wrote about how I could revise my code to create one AWS deployment container.
I had some existing templates to deploy resources in my stack that I started deploying here but there’s something I’m going to need to change about the way I deploy AWS credentials used by jobs.
I’m going to automatically deploy credentials for a user that can use in the job execution environment.
I wrote about creating secrets without exposing them to users in a prior post a long, long time ago…finally I’m using it with my batch job execution framework I started way back then but didn’t know exactly how it was going to turn out.
I’ll be leveraging but reworking this code a bit to work within the context of our job framework.
I’m going to deploy the user in the IAM account and credentials in the IAM account for the environment in which the credentials can operate. So for the environment I’m currently setting up I’m going to create the dev-admin user in the dev-IAM account. I need to restrict those credentials accordingly so they can only be used to deploy resources in the specified environment.
The EC2 job execution role needs permission to obtain the secrets for users in the same environment it is in. This means that the job execution role has to have cross-account access to the IAM account for any secrets that start with the name job- or whatever full prefix I end up using.
If we were only going to use those credentials with EC2 instances that pull down and execute jobs where the user passes MFA into the EC2 userdata then we would never need to give those credentials to a user. However, for local testing we will them to configure an AWS CLI profile we can use to to assume a role with MFA and obtain the short term credentials to pass to a container.
The initial user will be the environment admin. So for the dev environment it will be the dev-admin. The dev-admin can assume the dev-adminrole which is the organizations role in any account in that environment as explained in a prior post.
As with my prior example, the CloudFormation template will create the AWS credentials and immediately store them in Secrets Manager.
Here’s the format to create an AccessKey:
We can use the resulting reference and attributes to get the values we want to store in AWS Secrets manager:
We can use those values when creating an AWS Secret but we do *NOT* want to hardcode any values. We’re going to use !Sub and reference the above outputs in our code in the same template to get the secrets and push them into Secrets Manager as explained in the above post.
This is one of those rare instances where I’m not using Micro-Templates:
I’ll also use my environment KMS key to encrypt the secrets and grant access for users in the environment to use the key. The KMS key will be in the KMS account for the environment.
That means if you have production secrets, a user in the dev environment can’t see them because they don’t have permission to use keys from other environments.
The EC2 job execution role will also need access to use the KMS key, same as before, but we need to grant cross account access to the key for the role as well.
You could use more KMS keys to segregate access but for now I’m using a single key per environment for this initial test.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2024
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab
