ACM.93 Testing that the user we granted AWS Console access can see their user-specific secret in Secrets Manager
This is a continuation of my series on Automating Cybersecurity Metrics.
Alright, we now have a user that can log into the AWS console. I wanted to the secret in Secrets Manager. Login and make sure you are in the correct region. As it turns out, our policies do not allow the user to access the secret:
I’m going to guess that error is due to basic listing of services in the AWS console because now we are not just accessing a single secret, but let’s find out. Head on over to CloudTrail.
As I suspected. ListSecrets. Access Denied. We need to add that, even though the user should only have access to one secret.
I updated the user secret policy to add that permission.
Now, I mentioned in a prior post that my User template was creating a secret with a console password even for users that were not supposed to get console access and they didn’t. It is at this point I remember that I added an untested condition to the secret to only deploy it if the ConsoleAllowed condition is true:
Unfortunately AWS CloudFormation doesn’t work when you do that the way I have my template set up. I have a dependency on the Passwrd in my User resource:
So the user cannot be created unless the Password exists. As it turned out I don’t think the dependency was the problem. Let’s try to remove it.
I also removed the Password output at the bottom of the template that we added to confirm the incorrect password showing up when we referenced the password in the user Resource (an issue I still hope to resolve but am ignoring at the moment). This documentation doesn’t seem to be working as explained in the last post:
Using dynamic references to specify template values
Aha. I think I figured it out. I’m not sure if I am delusional but I think the documentation just changed or I was looking at a different page that said you could reference an object you created in CloudFormation but it wasn’t working no matter how I tried to do it. Then, as mentioned, I found a post referencing the full ARN of the secret on stack exchange — and now that appears in the above documentation. Maybe I was looking at a different page.
At any rate this deploys with no dependency and I think I was using this format last night and it wasn’t working but now it is.
Since we re-deployed the user I presume the password changed and all our extraneous secrets should be gone. Let’s check.
Well, one thing is interesting. If the password is different, it didn’t affect my active logged in session. That’s something to be aware of if you are trying to terminate user access to your cloud accounts.
Here’s some information about revoking roles. But our user is not using a role.
Revoking IAM role temporary security credentials
Hmm, I am not immediately finding a way to terminate an individual user’s IAM access. This is a good case for why you might not want to give any permission to a user but rather make them assume a role since you can terminate role sessions.
Anyway, let’s logout and log back in with the new password — an explanation of all that was in the last post.
So, this is intersting…
If the above is true then how was I able to set the password for this user last night? Let me close out and return to this page in an incognito window like I did last night. Odd. Somehow I could reset the password last night but not today. My developers need permission to change their own password. Thankfully there’s a policy for that:
Permitting IAM users to change their own passwords
Another version, slightly different:
AWS: Allows IAM users to change their own console password on the My Security Credentials page
I added that to my user specific secret policy because right now the only users that need access to the console are those with a secret. That may change later, in which case I might want to create a separate policy for password changes. Anyway, let’s test it out.
Well, I can now change the password and thankfully it did not remove MFA from before the change of password with CloudFormation.
I’ll also make one more note here that for console access, I would prefer to use a Yubikey, but I can only set one MFA device with AWS IAM. I did recently notice that you can set two in AWS SSO which is much better. That way you can have a backup. The other way around this would be to give users a two separate IAM accounts — one for console access and one for programmatic access.
But it still says I can’t list secrets. I know what the problem is…
This is something I always found odd with AWS policies. I have to give the user access to list ALL secrets even though they are only supposed to use one secret. The same is true for other policies like S3 bucket policies. I think it makes the policies more confusing than they need to be and I don’t *want* to allow my user to list all secrets. But that’s what we have to do.
So this:
Becomes this:
Ick. But let’s see if it works.
Refresh the page with the secret and yes, now I can see *ALL* the secrets unfortunately. I don’t want users to see all the secrets or all the buckets in my account if they are only supposed to access one. Same for application roles. I really wish AWS would fix that. #awswishlist.
However, when I click on a secret, I can’t see it. It’s not real pretty but it works:
I can open up the secret the Developer is supposed to be able to access, but can’t view the Secret value in the console. Is it just malformed or a permission issue?
Let’s check CloudTrail. Looks like we have a few issues:
And in case you can’t read that (I can’t) our developer needs these permissions;
Another permission I wish we did not have to add for this purpose:
Why does this user need to see every encryption Key alias to view a secret?
I don’t think we need to allow the developer to get the resource policy.
We have already granted KMS decrypt to the developer key in the IAM policy. Let’s check out our KMS policy. And yes:
Once again AWS has changed the KMS policy without warning to what I think is some sort of user ID. This is really problematic. If a user or role is ever deleted and recreated you need to redeploy your key policy. And make sure you don’t delete the user that administers the key!
Also just a reminder, the policy key won’t update with a CloudFormation stack that hasn’t changed, so I added a timestamp parameter to the policy to force the change in this case. I’m redeploying the key now…
And…I just remembered that I forgot to add back MFA for my KMS admin.
The fix is definitely to restore the user ARN above. The problems I had restoring the KMS admin warrants a blog post unto itself.
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)
____________________________________________
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: Console Access was originally published in Cloud Security on Medium, where people are continuing the conversation by highlighting and responding to this story.
