Consumer-Particular Secrets and techniques: Console Entry | by Teri Radichel | Cloud Safety | Oct, 2022

October 28, 2022

1

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

It is a continuation of my collection on Automating Cybersecurity Metrics.

Alright, we now have a person 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 enable the person 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’re not 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 person ought to solely have entry to at least one secret.

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

Now, I discussed in a previous put up 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 keep in mind 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 once you try this the way in which I’ve my template arrange. I’ve a dependency on the Passwrd in my Consumer useful resource:

So the person 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 substantiate the inaccurate password exhibiting up once we referenced the password within the person Useful resource (a problem I nonetheless hope to resolve however am ignoring for the time being). This documentation doesn’t appear to be working as defined within the final put up:

Aha. I believe I figured it out. I’m undecided if I’m delusional however I believe the documentation simply modified or I used to be a special web page that stated you possibly can reference an object you created in CloudFormation however it wasn’t working regardless of how I attempted to do it. Then, as talked about, I discovered a put up referencing the complete ARN of the key on stack alternate — and now that seems within the above documentation. Perhaps I used to be a special web page.

At any price this deploys with no dependency and I believe I used to be utilizing this format final evening and it wasn’t working however now it’s.

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

Nicely, one factor is attention-grabbing. 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 person entry to your cloud accounts.

Right here’s some details about revoking roles. However our person shouldn’t be utilizing a job.

Hmm, I’m not instantly discovering a strategy to terminate a person person’s IAM entry. It is a good case for why you won’t need to give any permission to a person however moderately make them assume a job since you possibly can terminate position classes.

Anyway, let’s logout and log again in with the brand new password — a proof of all that was within the final put up.

So, that is intersting…

If the above is true then how was I in a position to set the password for this person final evening? Let me shut out and return to this web page in an incognito window like I did final evening. Odd. Someway I may reset the password final evening however not in the present day. My builders want permission to alter their very own password. Fortunately there’s a coverage for that:

One other model, barely totally different:

I added that to my person particular secret coverage as a result of proper now the one customers that want entry to the console are these with a secret. Which will change later, by which case I would need to create a separate coverage for password adjustments. Anyway, let’s try 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 notice right here that for console entry, I would favor to make use of a Yubikey, however I can solely set one MFA machine with AWS IAM. I did just lately discover that you would be able to set two in AWS SSO which is a lot better. That method you possibly can have a backup. The opposite method round this is able to be to offer customers a two separate IAM accounts — one for console entry and one for programmatic entry.

However it nonetheless says I can’t checklist secrets and techniques. I do know what the issue is…

That is one thing I at all times discovered odd with AWS insurance policies. I’ve to offer the person entry to checklist 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 believe it makes the insurance policies extra complicated than they have to be and I don’t *need* to permit my person to checklist all secrets and techniques. However that’s what we have now 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. Identical for software 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 however 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 problem?

Let’s examine CloudTrail. Seems to be like we have now a number of points:

And in case you possibly can’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 person must see each encryption Key alias to view a secret?

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

We now 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 believe is a few type of person ID. That is actually problematic. If a person or position is ever deleted and recreated you have to redeploy your key coverage. And ensure you don’t delete the person that administers the important thing!

Additionally only a reminder, the coverage key gained’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 unquestionably to revive the person ARN above. The issues I had restoring the KMS admin warrants a weblog put up unto itself.

Teri Radichel

Should you favored this story please clap and comply with:

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