Person-Particular Secrets and techniques on AWS: IAM Insurance policies | by Teri Radichel | Cloud Safety | Oct, 2022 | Tech Do

ACM.82 IAM insurance policies to permit customers to explain their very own secrets and techniques

This can be a continuation of my collection of posts on Automating Cybersecurity Metrics.

Within the final put up, we created an SSH key for a person programmatically. I created a coverage for our Developer Group Function utilizing the $aws:username parameter which I anticipated would prohibit every person to solely accessing their very own secret.

Evidently we can’t see the key within the console. Extra on that later.

Drawback accessing a user-specific secret with a task

For those who keep in mind, I have never given you entry to the developer person console at the moment. I’d tackle this later, however for now let’s use the AWS CLI to see if the developer function can entry the key. I will have to arrange an AWS CLI profile for the developer function:

Now let’s examine if we are able to get the key utilizing the AWS CLI and developer profile. There’s one different factor we’ll have to repair. The describe-secret CLI command requires a secret ID that doesn’t precisely match our secret identify. Added some further characters on the finish.

We’ll want to regulate our Developer Group Function coverage:

That is not an excellent answer. Somebody may manipulate a username so as to add hyphens to it and entry our secret. What if somebody may create a username “Developer-1” after which attempt to entry our secret? This coverage would grant them entry.

We even have one other downside. Utilizing the AWS CLI with the assumed function, the username is No our developer person. It’s the identify of the function: DevelopersGroup.

Do not forget that we gave the username entry to the key, not the function or group as a result of we need to implement non-repudiation. (See earlier publications).

Apply the coverage to a gaggle

What if we apply the coverage to a gaggle as a substitute of the function? Would the coverage then be accurately utilized to a username? It may, however we nonetheless have the above downside. The key identify doesn’t match the developer identify. If we use a * within the coverage, we may find yourself with unintended penalties as defined above.

Utility of a user-specific coverage

What occurs if we attempt to entry the key with a user-specific AWS CLI profile as a substitute of the function?

DescribeSecret on useful resource: Developer-fnL9lq as a result of no identity-based coverage permits the secretsmanager:DescribeSecret motion

Now we have not particularly granted any permissions on to the person, we solely grant permission to imagine the DeveloperGroup function. We have to take away the permission from the function and apply it to the person as a substitute.

It’s typically not an excellent apply to create user-specific insurance policies in AWS. Actually, I’d criticize you for it in a safety evaluation in sure circumstances. Nevertheless, on this case, every particular person coverage is exclusive and the coverage should be eliminated or disabled with the person. The coverage may be very particular and has a function. Now we have a single template to use the identical coverage to all customers, so if that you must replace it, replace it as soon as and redeploy it to all customers.

It could be rather a lot simpler if AWS would simply create the key with the identify we specified within the ARN (#awswishlist). That may additionally be sure that our secret names are distinctive we may merely reference the username within the template as a substitute of wanting up the key identify and making a per-user coverage.

There are execs and cons to this method, however we are able to get a really particular coverage that provides the person solely entry to their very own secret. Attributable to secret naming conventions, I do not see every other technique to do it so cleanly in the meanwhile with out including a harmful asterisk. Let’s strive.

If we would have liked to disable or delete a person, we would want to delete the person’s particular secret and SSH key, the identical manner you’d delete or disable a username and password. It’s possible you’ll need to create a service management coverage that stops a person from being deleted till their user-specific secret has been deleted or maybe disabled ultimately so they do not have orphaned secrets and techniques. I would like to consider that some extra.

Create a secret per person with CloudFormation

What occurs if we create a person secret for a person with CloudFormation and move our SSH key as a parameter when creating the key?

The place would that parameter find yourself? Do not forget that the parameters seem read-only within the AWS console:

We can also’t create a secret with none worth that we are able to replace later. So we must move one thing to our secret worth. We do not need to move any delicate knowledge as a result of it should find yourself within the AWS console in plain textual content for anybody with entry to learn.

Creating the key in CloudFormation helps us shield a secret we’re creating, however permits us to get the key id as output. However as you might keep in mind, we are able to get that secret ID after we create it with a CLI command additionally within the earlier put up.

Which answer works finest for us? Nicely, now we have one other downside that we’ve not addressed but: if the key already exists, we won’t recreate it. If we use the CloudFormation implementation command which can maintain whether or not the key must be created or up to date. We may do this with our personal code, however why create extra work for ourselves? We are going to use CloudFormation to create the key.

Create a secret with CloudFormation

We are able to change our script to create a secret with CloudFormation in order that it creates or updates the key as wanted. We are going to set a default worth for the key and overwrite it with the SSH key in a later step.

Word that, as defined above, we are able to see that the parameter we used to set a default worth for our secret is seen in clear textual content within the AWS console. Do not move secret values ​​as parameters to AWS Secrets and techniques Supervisor.

Even in the event you use NoEcho… a number of caveats right here:

For those who look within the CloudTrail logs for the UpdateSecret entry, you will see that the key worth is not current. You’d solely want to think about the place it’d exist on the system the place you make the API name.

Right here is our up to date perform the place:

• Verify if the important thing already exists
• Create or replace the key
• Replace the key with the worth of the SSH key
• Replace the person coverage to permit the person to entry their very own secret

That is the coverage that permits the person to acquire the worth of their very own secret.

Take away the permissions we tried so as to add to the Developer Roles Coverage.

Now take a look at to see if the developer can entry your individual secret:

aws secretsmanager describe-secret --secret-id Developer --profile developeruser

Sure!

There may be one different factor we are able to and doubtless ought to add to this coverage as it’s not a task and we need to guarantee that solely the precise developer can entry their very own secret. Know what it’s?

Including an MFA Situation to an IAM Person Coverage

We are able to add an MFA situation. I’ve written in regards to the MFA situation documentation earlier than right here:

I believe we are able to verify if MFA is current with out ifexists, however let’s do this:

Situation:
"Bool": 
"aws:MultiFactorAuthPresent" : "True"

That rolls out, now let’s examine if we are able to nonetheless entry our secret. Nope:

An error occurred (AccessDeniedException) when calling the DescribeSecret operation: Person: arn:aws:iam::xxxx:person/Developer isn't approved to carry out: secretsmanager:DescribeSecret on useful resource: Developer as a result of no identity-based coverage permits the secretsmanager:DescribeSecret motion

As soon as once more, this error message is deceptive. I would really like it to specify that the situation isn’t met. In any case, let’s examine what the request seems like in CloudTrail.

To seek out the motion that brought about the error, I needed to search by username.

For some purpose, I did not discover it after I looked for AWS Secrets and techniques Supervisor Secret as a useful resource.

You could possibly additionally discover it by looking for DescribeSecret:

Nicely, have a look at that. There isn’t any MFA worth in any respect on this request, regardless that I configured my person within the CLI to make use of MFA:

So that is the place the “long-term credentials” come into play with their MFA circumstances that I wrote about within the earlier put up. Apparently there is no such thing as a technique to implement MFA for this motion for a single person utilizing a programmatic credential or they will not have the ability to get the key programmatically.

If we take away MFA, then if a developer has hard-coded credentials on their native laptop computer, then somebody may use them with out MFA to get this user-specific secret programmatically. That’s fairly unlucky.

What occurs if we take away the MFA situation? As soon as once more we are able to entry our secret and curiously now the Useful resource Sort accurately returns an AWS::SecretsManager:Secret

Maintain the above in thoughts if you’re making an attempt to put in writing alerts associated to lack of entry to a Secrets and techniques Supervisor secret and are looking out by useful resource sort; at all times take a look at your alerts with actual values.

Nicely, for example we add “if exists” to our coverage as beneficial within the AWS documentation. Does that actually assist us? As I’ve written earlier than, no. On this case, MFA doesn’t exist when somebody makes use of long-term credentials. So if we have been so as to add if exists, our situation would merely not apply when the situation doesn’t exist, which isn’t the case within the above state of affairs. I really feel just like the AWS documentation is not precisely clear on this level and makes it seem to be the “if exists” possibility is ok when it actually is not in the event you actually need to apply MFA.

We’ll have a look at a number of the different actions the person took and see if MFA reveals up anyplace else in a later put up. For now, I’ve eliminated the MFA requirement till we are able to take a look at different actions.

Observe for updates.

Teri Radichel

For those who like this story please applaud Y proceed:

Medium: Teri Radichel or E mail Checklist: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests providers by way of LinkedIn: Teri Radichel or IANS Analysis

© second sight lab 2022

All posts on this collection:

____________________________________________

Writer:

Cybersecurity for executives within the cloud period at Amazon

Do you want cloud safety coaching? 2nd Sight Lab Cloud Safety Coaching

Is your cloud safe? Rent 2nd Sight Lab for a penetration take a look at or safety evaluation.

Do you could have a query about cybersecurity or cloud safety? Ask Teri Radichel by scheduling a name with IANS Analysis.

Cybersecurity and Cloud Safety Assets by Teri Radichel: Cybersecurity and cloud safety lessons, articles, white papers, displays, and podcasts