User-Specific Secrets: Console Access | by Teri Radichel | Cloud Security | Oct, 2022 | Tech Ado

ACM.93 Testing that the consumer we granted AWS Console entry can see their user-specific secret in Secrets and techniques Supervisor

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

Alright, we now have a consumer that may log into the AWS console. I needed to the key in Secrets and techniques Supervisor. Login and ensure you are within the appropriate area. Because it seems, our insurance policies don’t permit the consumer to entry the key:

I’m going to guess that error is because of fundamental itemizing of companies within the AWS console as a result of now we aren’t simply accessing a single secret, however let’s discover out. Head on over to CloudTrail.

As I suspected. ListSecrets. Entry Denied. We have to add that, despite the fact that the consumer ought to solely have entry to at least one secret.

I up to date the consumer secret coverage so as to add that permission.

Now, I discussed in a previous submit that my Consumer template was making a secret with a console password even for customers that weren’t imagined to get console entry they usually didn’t. It’s at this level I do not forget that I added an untested situation to the key to solely deploy it if the ConsoleAllowed situation is true:

Sadly AWS CloudFormation doesn’t work if you do this the way in which I’ve my template arrange. I’ve a dependency on the Passwrd in my Consumer useful resource:

So the consumer can’t be created until the Password exists. Because it turned out I don’t assume the dependency was the issue. Let’s attempt to take away it.

I additionally eliminated the Password output on the backside of the template that we added to verify the inaccurate password exhibiting up after we referenced the password within the consumer Useful resource (a difficulty I nonetheless hope to resolve however am ignoring in the mean time). This documentation doesn’t appear to be working as defined within the final submit:

Aha. I feel I figured it out. I’m undecided if I’m delusional however I feel the documentation simply modified or I used to be taking a look at a unique web page that stated you can reference an object you created in CloudFormation nevertheless it wasn’t working regardless of how I attempted to do it. Then, as talked about, I discovered a submit referencing the total ARN of the key on stack change — and now that seems within the above documentation. Perhaps I used to be taking a look at a unique web page.

At any fee this deploys with no dependency and I feel I used to be utilizing this format final night time and it wasn’t working however now it’s.

Since we re-deployed the consumer I presume the password modified and all our extraneous secrets and techniques ought to be gone. Let’s verify.

Nicely, one factor is fascinating. If the password is totally different, it didn’t have an effect on my energetic logged in session. That’s one thing to concentrate on in case you are making an attempt to terminate consumer entry to your cloud accounts.

Right here’s some details about revoking roles. However our consumer will not be utilizing a task.

Hmm, I’m not instantly discovering a solution to terminate a person consumer’s IAM entry. This can be a good case for why you won’t need to give any permission to a consumer however quite make them assume a task since you’ll be able to terminate function periods.

Anyway, let’s logout and log again in with the brand new password — an evidence of all that was within the final submit.

So, that is intersting…

If the above is true then how was I in a position to set the password for this consumer final night time? Let me shut out and return to this web page in an incognito window like I did final night time. Odd. In some way I might reset the password final night time however not at present. My builders want permission to vary their very own password. Fortunately there’s a coverage for that:

One other model, barely totally different:

I added that to my consumer particular secret coverage as a result of proper now the one customers that want entry to the console are these with a secret. That will change later, through which case I would need to create a separate coverage for password modifications. Anyway, let’s check it out.

Nicely, I can now change the password and fortunately it didn’t take away MFA from earlier than the change of password with CloudFormation.

I’ll additionally make yet another observe right here that for console entry, I would favor to make use of a Yubikey, however I can solely set one MFA system with AWS IAM. I did lately discover you could set two in AWS SSO which is a lot better. That manner you’ll be able to have a backup. The opposite manner round this is able to be to present customers a two separate IAM accounts — one for console entry and one for programmatic entry.

But it surely nonetheless says I can’t listing secrets and techniques. I do know what the issue is…

That is one thing I all the time discovered odd with AWS insurance policies. I’ve to present the consumer entry to listing ALL secrets and techniques despite the fact that they’re solely supposed to make use of one secret. The identical is true for different insurance policies like S3 bucket insurance policies. I feel it makes the insurance policies extra complicated than they have to be and I don’t *need* to permit my consumer to listing all secrets and techniques. However that’s what we’ve got to do.

So this:

Turns into this:

Ick. However let’s see if it really works.

Refresh the web page with the key and sure, now I can see *ALL* the secrets and techniques sadly. I don’t need customers to see all of the secrets and techniques or all of the buckets in my account if they’re solely imagined to entry one. Similar for utility roles. I actually want AWS would repair that. #awswishlist.

Nevertheless, after I click on on a secret, I can’t see it. It’s not actual fairly nevertheless it works:

I can open up the key the Developer is meant to have the ability to entry, however can’t view the Secret worth within the console. Is it simply malformed or a permission difficulty?

Let’s verify CloudTrail. Seems like we’ve got a couple of points:

And in case you’ll be able to’t learn that (I can’t) our developer wants these permissions;

One other permission I want we didn’t have so as to add for this objective:

Why does this consumer must see each encryption Key alias to view a secret?

I don’t assume we have to permit the developer to get the useful resource coverage.

Now we have already granted KMS decrypt to the developer key within the IAM coverage. Let’s take a look at our KMS coverage. And sure:

As soon as once more AWS has modified the KMS coverage with out warning to what I feel is a few type of consumer ID. That is actually problematic. If a consumer or function is ever deleted and recreated you should redeploy your key coverage. And ensure you don’t delete the consumer that administers the important thing!

Additionally only a reminder, the coverage key received’t replace with a CloudFormation stack that hasn’t modified, so I added a timestamp parameter to the coverage to drive the change on this case. I’m redeploying the important thing now…

And…I simply remembered that I forgot so as to add again MFA for my KMS admin.

The repair is certainly to revive the consumer ARN above. The issues I had restoring the KMS admin warrants a weblog submit unto itself.

Teri Radichel

If you happen to preferred this story please clap and comply with:

Medium: Teri Radichel or E-mail Record: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests companies by way of LinkedIn: Teri Radichel or IANS Analysis

© 2nd Sight Lab 2022

All of the posts on this sequence:

____________________________________________

Creator:

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 courses, articles, white papers, displays, and podcasts