AWS EC2 KeyPair creation with CloudFormation does not have a decent way to restrict a user to seeing their own SSH key

Keys are created in SSM Parameter store with random names that cannot easily be used in policies

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics | Code.

🔒 Related Stories: Bugs | AWS Security | Secure Code

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Just wrote about this in a more detailed explanation of using CloudFormation to deploy an SSH key here:

AWS CloudFormation adds the EC2 key pair to SSM Parameter store with a random name which cannot easily be used in policies to restrict users to seeing their own SSH keys.

I’ve shown in prior posts how to create policies with ${aws::username} and that doesn’t work the way these parameters are named. Anyone with read access to the parameters can see the SSH keys in them.

Typically when you perform a security audit you ask for read only access to an account to perform the audit. Also, does the AWS security audit role have access to these keys? Administrators using the full access policy will also have access to these keys. It’s like giving administrators everyone’s passwords. Yes they may be able to reset them but the user will know when they cannot access the system. With an SSH key the user has no idea anyone else is using the key.

Even if these parameters did have an appropriate name, the problem with SSM Parameter store is that you cannot apply resource policies to SSM Parameters to limit who can access the resource. It’s much more challenging to do this across all of IAM or try to manage this in a Service Control Policy when users are adding and removing SSH Keys frequently (which is generally what happens in larger organizations if they use SSH keys).

A better solution would be to let the customer specify a Secret in Secrets Manager where they wish to store the key at the time of creation, and allow the customer to configure the secret at that time. The customer could also specify a Parameter encrypted with a customer managed key that limits access to a particular user, but the key also has an administrator and the key solution seems like it would be more expensive. Alternatively, let the customer specify a KMS key and change parameter store to allow creation of resource policies (Not the policies currently applied to SSM Parameters which do not serve the same purpose).

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

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 Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow 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