ACM.81 Altering code that makes use of SSM Parameter Retailer to make use of AWS Secrets and techniques Supervisor
It is a continuation of my sequence of posts on Automating Cybersecurity Metrics.
I’ve been writing about creation of an EC2 SSH Key to be used with an EC2 occasion. I defined that I wish to create the important thing in a way that gives non-repudiation and solely permits a licensed consumer to entry their very own key. These ideas and the prior code we created to create and retailer the SSH Key in SSM Parameter retailer are lined within the prior posts.
Right here’s the code together with the shred command mentioned within the submit on when deleted recordsdata should not actually deleted.
Now we’re going to change this code to retailer the credentials in Secrets and techniques Supervisor as a substitute. We’re going so as to add a KMS key and solely permit builders to make use of the KMS key.
Developer Group and Function
Earlier than we create a KMS key for our secret we have to create a Developer Group and Function. I at present have my developer consumer assigned to an “AppDeployment” group. Nevertheless, no matter is deploying purposes mustn’t have entry to developer SSH keys. I desire a group particular to builders on this case. It’s straightforward to make use of our current code so as to add a brand new group and add the Developer IAM Consumer.
It’s additionally straightforward so as to add a brand new position through the deployment script.
We additionally want so as to add the position coverage that perform is anticipating that permits the builders to entry Secrets and techniques Supervisor and the Developer KMS key. With a view to create the coverage that permits builders to make use of the important thing, we first must create the important thing.
A little bit of refactoring earlier than we create our KMS key
Subsequent we have to create a KMS key for the developer group to make use of. As a result of our insurance policies can limit entry with IAM on a per developer foundation we don’t want a KMS key for every developer on this case, however we might do this if we had a high-security atmosphere that wanted further safety for additional safety.
Including a brand new key ought to have been straightforward however by some means I forgot to verify in some prior code so I fastened that. I must also point out for these following alongside from the start that I eliminated some error checking within the deploy.sh script for KMS keys that checks for an empty output worth and moved it to the perform the place I get the output worth from a stack.
Additionally, I’ve began to understand that the “service” identify I give my CloudFormation stacks usually match my AWS CLI values. Ultimately I’ll get rid “service” and simply use “profile” as a substitute.
The profile and repair variables each exist in my shared perform bash scripts now for every subdirectory. I can take away passing the profile into each perform name. Little by little I’m streamlining the code the place I can so there’s much less of it.
Including a brand new KMS key for the Builders Group
It’s straightforward so as to add a brand new key to our key deployment stack. Copy and modify the code for the important thing above it:
And add an alias by copying and altering considered one of our different aliases:
Replace the Developer Function IAM Coverage
Now we would like our Developer Function to have the ability to use their very own coverage and builders want to have the ability to entry a secret with a reputation matching their very own.
So right here’s what I needed to do. I needed to make use of the ${aws:username} parameter the way in which you should utilize it in an IAM change password coverage like this:
I attempted so as to add the aws:username variable to my coverage like this:
It didn’t work. Why. What if the Sub isn’t correctly dealing with the username as a variable? If I take away the Sub and added the useful resource like this:
"*:secret:${aws:username}"
Can’t do this both:
What if I simply use * from the area and account id?
"arn:aws:secretsmanager:*:*:secret:${aws:username}"
CloudFormation deployed the above. I’d slightly have a selected account quantity and area. Looking round I discovered this query on the way to escape a ${} in a Sub perform:
Let’s attempt it.
"arn:aws:secretsmanager:${AWS::Area}:${AWS::AccountId}:secret:${!aws:username}"
Nope:
Nicely, our coverage isn’t excellent however it’s fairly shut. It could be good if AWS would repair Sub to exclude the particular worth aws:username. #awswishlist.
However will it work? See subsequent posts for a working resolution. For now let’s retailer our SSH Key in Secrets and techniques Supervisor.
Replace SSH key creation perform to make use of Secrets and techniques Supervisor
Final we wish to change our deployment script to save lots of the brand new SSH key to Secrets and techniques Supervisor as a substitute of parameter retailer. Right here’s the command we wish to use:
Whereas we’re at it, we are able to get rid of storing the important thing to a file in any respect and rework it in reminiscence after which instantly add it to secrets and techniques supervisor. I needed to repair a bug within the delete and re-create logic from the final submit.
In fact we’ve got to provide the IAM administrator permissions to create the secrets and techniques and use the important thing.
Change the important thing coverage to provide the IAM permission to create (encrypt) the important thing.
Presuming you’re utilizing my up to date code the place I fastened a typo, the code ought to now deploy a secret and retailer the SSH key we cerated in Secrets and techniques Supervisor, encrypted with the desired KMS key.
Nevertheless, as you will note in subsequent posts, though we obtained our code to deploy the key and retailer the worth, we’ve got some points with our insurance policies. We have to make some changes to permit customers to entry their very own secrets and techniques, and nobody else’s secrets and techniques, whereas sustaining non-repudiation (which means the IAM admin nor the KMS admin can view the secrets and techniques both.)
Comply with for updates.
Teri Radichel
In the event you favored this story please clap and comply with:
Medium: Teri Radichel or E mail Listing: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests providers through LinkedIn: Teri Radichel or IANS Analysis
© 2nd Sight Lab 2022
All of the posts on this sequence:
____________________________________________
Creator:
Cybersecurity for Executives within the Age of Cloud on Amazon
Want Cloud Safety Coaching? 2nd Sight Lab Cloud Safety Coaching
Is your cloud safe? Rent 2nd Sight Lab for a penetration check or safety evaluation.
Have a Cybersecurity or Cloud Safety Query? Ask Teri Radichel by scheduling a name with IANS Analysis.
Cybersecurity & Cloud Safety Assets by Teri Radichel: Cybersecurity and Cloud safety courses, articles, white papers, displays, and podcasts
