ACM.83 Leveraging Resource Policies vs IAM Policies to prevent unintended access to secrets in Cloud Environments
This is a continuation of my series of posts on Automating Cybersecurity Metrics.
Note that I started working on this diagram but I amend it in a later post for greater accuracy and alignment with our policy objectives.
In our last post we started creating a user-specific secret, which was an SSH key for a specific user. Only that user should be able to access their own SSH key in secrets manager. We implemented some initial code with IAM policies.
Create a Per-User Secret in Secrets Manager: Part 1
We want to deploy secrets in an automated fashion that only a specific user can access to retrieve the value. There are two sides to securing a secret. On the one hand, you need to create an IAM policy. In addition, we need to create a resource policy on the secrets themselves.
Beyond that, and outside the scope of this post — you need to have a deployment pipeline and software development lifecycle (SDLC) that prevents users from altering these policies to access the secrets. That’s the type of question I answer for clients on IANS Research calls. In this post, we’re going to finish setting up our policies resource policies so only authorized users can view their own secrets.
In this post, we will consider the structure of the IAM and resource policies to protect an encrypted secret and why they matter.
Do we need a resource policy?
First of all, if we don’t put any policies on our secret, any can get it. What if we encrypt it? Well, if we don’t put any policies on our encryption key, then anyone in our account that is allowed to use KMS can use it to decrypt the SSH key stored in secrets manager.
It seems like a resource policy would be a good idea right? But do we need both the encryption key and secrets manager resource policy to be restricted to specific users?
I’ve been modifying a single CloudFormation template to deploy all our keys with a well-designed key policy because so many errors occur when trying to get it right. Using one well-tested working policy will help us prevent errors and hopefully speed up deployments.
Using a key policy will help protect the data because people will need access to a specific key to decrypt the data used to encrypt that key as opposed to anyone with KMS decryption permissions in the account having access.
You can read about key policies here and explore prior posts for a myriad of considerations.
Unfortunately, due the way that KMS key policies work, we have to give our IAM administrators who create the SSH Key and store it in Secrets Manager both encrypt and decrypt permissions. As I’ve already explained this seems like a design flaw but that’s how it works.
That means that the IAM admins would be able to decrypt the value of the SSH key — if they can retrieve it from Secrets Manager.
If we create a secrets manager resource policy that IAM Administrators cannot edit, and it can restrict them from getting the secret (using the secrets manager get-secret-value command), then their permission to decrypt the value doesn’t help them access the secret.
AWS::SecretsManager::ResourcePolicy
They cannot “get” the encrypted secret to decrypt.
get-secret-value – AWS CLI 2.8.2 Command Reference
If the IAM Administrators have permission to both edit their own IAM policies, and edit the secret resource policy, then obviously they can get the secret and decrypt it. We will address that later.
We want to grant all developers access to use the developer resources decryption key to save money as already explained. However, we don’t want developers to be able to decrypt each other’s keys. So we can create a resource policy on each developer’s personal secret that limits them to accessing their own secret and no one else’s.
KMS administrators create the key policy. They might be able to change it to grant themselves access to use the key to decrypt data. However, a resource policy on the secret would prevent them from “getting” the encrypted value, same as for IAM administrators described above. Decryption permissions alone don’t help them.
We could segregate duties as follows:
IAM admins have permission to set IAM policies but they cannot grant themselves additional permissions in their own policy or create resources that use the permissions in the policies they create.KMS admins create KMS Key Policies but not policies on data and secret resources.AppSec admins set the resource policies for secrets, parameters, and data.
For the last bullet, different people might have different permissions to edit resource policies. You might have automated processes, or limits on the permissions users can grant. Maybe you have a team responsible for application security separate from those who manage KMS keys and IAM. For the framework we are developing I’m going to eventually create a role for this purpose.
Of course, you would need a super admin (something I am going to call the ROOT AWS cli profile in later posts) to set up the initial policies to enforce that segregation of duties. Perhaps you setup these initial permissions and have a process that requires multiple people to use those privileges after initial setup with different people to approve and make changes with those credentials.
I’m getting a bit more high-security than I want to implement right now, so I’m going to start by having the IAM administrators set the policy on the Secret that contains the SSH key.
For now, be aware of these nuances when creating IAM and resource policies spanning multiple services. In our case, these are important considerations if we want non-repudiation for SSH keys as explained in a prior post.
Next, we’ll adjust our KMS key policy to allow Developers to use it to decrypt their secrets.
Teri Radichel
If you liked this story please clap and follow:
Medium: Teri Radichel or Email List: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests services via LinkedIn: Teri Radichel or IANS Research
© 2nd Sight Lab 2022
All the posts in this series:
Automating Cybersecurity Metrics (ACM)GitHub – tradichel/SecurityMetricsAutomation
____________________________________________
Author:
Cybersecurity for Executives in the Age of Cloud on Amazon
Need Cloud Security Training? 2nd Sight Lab Cloud Security Training
Is your cloud secure? Hire 2nd Sight Lab for a penetration test or security assessment.
Have a Cybersecurity or Cloud Security Question? Ask Teri Radichel by scheduling a call with IANS Research.
Cybersecurity & Cloud Security Resources by Teri Radichel: Cybersecurity and Cloud security classes, articles, white papers, presentations, and podcasts
User-Specific Secrets on AWS: Separation of Duties was originally published in Cloud Security on Medium, where people are continuing the conversation by highlighting and responding to this story.
