KMS Keys for AWS Organizations Environments

ACM.358 A common template for key deployment that includes organization and environment names — logs, deploy, and appdata keys

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

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

🔒 Related Stories: AWS Security | Secure Code | IAM | AWS Organizations

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

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

In my last post I was thinking about naming conventions for resources in AWS environments (like Dev, QA, Prod, and maybe others).

I have something else to fix that led me to thinking about environments and their associated resources.

While deploying S3 resources, I realized that I had a need for cross-account access to KMS keys. I also have future plans for deploying KMS keys differently but for now I am going to revamp my KMS keys like this. I’m going to create three KMS keys for my Sandbox environment:

AppData
Deploy
Logs

I’m going to delete the keys in the SandboxWeb account and reference the KMS keys from the Sandbox account instead. The SandboxAdmin will always be the administrator of these keys.

I was already messing around with deploying a KMS key for the Sandbox account in an environment setup script under my Org/Environment folder in the code (which I need to get up in the GitHub repo but it’s kind of a mess, sorry. I need to clean it up.)

I’m going to deploy the three keys here, sticking with the current model of code for the minute. I am thinking about an alternate approach. But for now I copy and paste and replicate that code, changing the key names and the ARNs that are allowed to encrypt, decrypt, and services that can use the key depending on the use case.

Recall that I was passing in an environment parameter:

Now the environment is in SSM so I’m going to remove that. I also added the admin account to SSM Parameters, but these keys are all currently deployed in the SandboxAdmin account. The role name allowed to administer the key going forward will be:

[Env]-[Org]-AdminRole

That means I’m going to have to assume a SandboxAdminRole to deploy and administer the keys and allow my SandboxAdmin to assume that role (with an MFA condition!) I created that role manually for now using methods I’ve explained in many other posts so not reiterating that here.

Now that I have a standard role I don’t have to pass in the environment name. I can pull that from SSM and concatenate the role.

As mentioned earlier, I don’t actually like using SSM parameters in CloudFormation because unlike Parameters, you don’t have a record of what got passed into the template but you do see the outputs. That sort of tells you what was passed in I guess. It makes troubleshooting a bit more challenging.

I’m still think about that but leaving it for now. If AWS would add SSM Parameters to the list of Parameters passed into the template that would help. #awswishlist

Now if you thinking about the above role name for a minute, if I wanted to move all my KMS keys to a single account and I called that environment “KMS” the above admin name would still work. I’d need to modify some other templates I’m going to use in my Sandbox environment at the moment but not much.

While going through this exercise and in conjunction with recent posts I decide I’m just going to make everything lowercase going forward. It’s ugly but it is consistent and works everywhere. So I made “Admin” lowercase in the above code and renamed my role to be all lowercase.

sandbox-[org]-admin

I also add the environment and org parameters to my key alias name in the alias template. That means if I create a script to create a new environment I don’t have to pass in the environment name when I run the script. It looks and works pretty much the same for any environment because it uses the parameters I created in the last post.

To state that another way, I create a Sandbox and a Staging environment. I set up the parameters in the accounts where I’m deploying the accounts when I create the accounts. Then I run my script to create the keys. The same key creation script runs in either environment with no changes because it pulls whatever the value of Environment and EnvironmentOrg is out of the parameters to create the keys. If the same script is run in both environments, both will end up with a logs, appdata, and deploy KMS key with the corresponding organization and environment in the key alias.

Now that I’ve got my keys set up in my Sandbox (SandboxDeploy) account, I need to adjust my other scripts that deploy my ECR repository, CodeCommit, S3 bucket and so on to use these keys. For now I’m just going to try to get my bucket working and the trigger that pushes the code to the bucket when the repository is updated. I’ll probably change the rest when I make bigger changes later.

I should also note that in a production environment I would likely override these keys to give sensitive applications their own keys, but in a dev environment we may not need that. It depends on the organization. You can also create different dev environments (account structures) for different lines of business or trust levels.

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