ACM.78 Automated creation of an AWS EC2 SSH key saved in AWS
This can be a continuation of my sequence on Automating Cybersecurity Metrics.
I wrote about completely different authentication mechanisms within the final submit.
Now let’s have a look at how we’d automate the deployment of an SSH key that enables a person to log into an EC2 occasion.
This implementation has some safety issues that we are going to repair within the subsequent few posts. I assumed it was going to be easy...however it wasn't.
An SSH key identifies a person (as do any credentials you assign to a person)
An SSH key ought to belong to a single person. It identifies that person as the one who related on a sure day and time to a bunch. We will going so as to add our SSH key creation code to our widespread IAM features and have the IAM staff handle the deployment of SSH keys — however the IAM staff ought to by no means have entry to the keys that belong to different customers. See the final submit for an outline of non-repudiation and why it is necessary for safety.
We’re going to create a key related to a person on the time we create the person. The bottom line is going to have the identical identify because the person. We’ll create it within the IAM listing of our code utilizing the IAM CLI profile as it’s tied to person id.
Create an SSH Key and retailer it in AWS Parameter Retailer
Right here’s some code that creates a key and shops it in AWS Parameter retailer. I put in in my user_functions.sh file in my IAM Customers listing. The profile with reference the IAM Profile included within the file.
I’m going so as to add a parameter to my create person perform that signifies whether or not a key needs to be created for that person or not.
I’m going to examine if that worth is “y” and if that’s the case, name the perform to create the person key.
Over in my deploy.sh file I’m going to go in “y” or “n” indicating whether or not I wish to create a key or not for every person. For now, I’m solely going to create an SSH key for the Developer person.
OK now run the deploy script.
Error: No permission. What permissions do we want?
ec2 create-key-pair
ec2 wait key-pair-exists
aws ssm put-parameter
What’s attention-grabbing to me is that an SSH key’s actually an IAM management, however it exists below EC2. That has implications to your IAM permission administration. If you happen to give somebody ec2.* permission that individual can do two issues that are tremendous essential for cloud safety:
- Change networking
- Deploy SSH keys
So an individual might arrange a brand new community with entry to your delicate sources in no matter account they’re in and set up a brand new ec2 occasion with an SSH key, login, and connect with different sources in your community. If something just isn’t protected with IAM controls, encryption, and key insurance policies, then that person may be capable of get to it.
The ethical of the story: Watch out with * in IAM Insurance policies!
We nonetheless want to return and restrict our community admin permissions to a zero belief coverage once we are via deploying community controls. For now let’s add the mandatory permissions to our IAM Admin group function coverage.
Use the deploy_iam_role.sh deployment script to deploy the function. Deploy once more. My script labored the primary time however not the second time as a result of I would like so as to add a line to delete the important thing if it already exists after which add that permission to the IAM admin group coverage.
You might have seen I’m utilizing a command with the phrase “Waiter” in it. That key phrase causes the command to attend for the exists of a useful resource, on this case a key pair.
Apparently the KeyPairExists command additionally requires ec2.DescribeKeyPairs.
And…it really works.
It really works! We’re executed proper?
Not fairly. Let’s ponder our script for a minute. How does it work? It downloads the SSH key and shops the output in a file. It then manipulates that file output to drag out a sound.pem file we are able to use as an SSH key to log into an AWS host. (It has saved the general public key on AWS to be used with EC2 situations.)
So the place did these two information find yourself?
They’re in our residence listing (specified by ~ under):
Anybody who can entry this host — or it’s backups — would have entry to these keys. Somebody might additionally detach the EBS quantity (digital drive) and connect it to a different occasion. Somebody might create a picture of this machine and launch one other one identical to it to entry these information.
Nicely, we might delete these keys. That ought to remedy the issue proper? Not precisely. I’ll present you why within the subsequent submit.
What different drawback do we have now? We needed to give the IAM admin full entry to create and delete parameters in SSM. Is that OK? Possibly it’s, possibly it isn’t. It will depend on whether or not you retailer delicate information in Parameter Retailer or not and whether or not you encrypt it.
Talking of encryption, we didn’t encrypt our credentials. Anybody who has entry to Parameter retailer can see them. As already talked about, if we use Parameter retailer we are able to’t assign a useful resource coverage to limit entry to our parameters so we must use an encryption key with restricted entry to unravel this drawback.
So if we create a KMS key and assign it to a person then we are able to create the credentials and even the IAM administrator can’t see them as solely that person could be allowed to encrypt and decrypt with that key. What’s the potential draw back of that method? We’ve got to pay $1 per encryption key on AWS final time I checked. When you have 11,000 builders like Capital One did after I was there, that’s $11,000 per thirty days. Is that okay? Possibly it’s, possibly it isn’t.
Is there an alternate? We will retailer the credentials in Secrets and techniques Supervisor. If we retailer the credentials in Secrets and techniques supervisor, then we are able to create a coverage to auto-rotate the credentials. We will additionally create a coverage that solely permits the precise developer who owns the credentials to entry them. We might use a generic key for encrypting credentials, however then we’re nonetheless paying extra for Secrets and techniques Supervisor. What’s the distinction?
Total, if I’m this appropriately, parameter retailer with a KMS key per person would value $1.05 per thirty days whereas Secrets and techniques supervisor with a single KMS key for all builders however a coverage proscribing every developer to solely entry their very own SSH Key secret would value .40 per person plus $1 per thirty days. If you happen to solely have one person then it’s $1.05 vs. $1.40. When you have two customers, then Secrets and techniques Supervisor is trying like a greater possibility. The operations value the identical.
Alright we want to consider how we’re going to repair the above points. Keep tuned for the following submit.
Teri Radichel
If you happen to appreciated this story please clap and observe:
Medium: Teri Radichel or Electronic mail Checklist: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests companies through LinkedIn: Teri Radichel or IANS Analysis
© 2nd Sight Lab 2022
All of the posts on this sequence:
____________________________________________
Writer:
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 Sources by Teri Radichel: Cybersecurity and Cloud safety lessons, articles, white papers, displays, and podcasts
