AWS Secret Manager - Grants Everyone access when only a specific list of principals were set

446 Views Asked by At

I can see that there is a policy evaluation rule for Secrets Manager here.

https://docs.aws.amazon.com/secretsmanager/latest/userguide/determine-acccess_understanding-policy-evaluation.html

I have a policy attached to the secrets manager resource as follows

{
  "Version" : "2012-10-17",
  "Statement" : [ {
    "Sid" : "minimumNeeded",
    "Effect" : "Allow",
    "Principal" : {
      "AWS" : [ "arn:aws:sts::SLJFLSDKFJLSJDKF:assumed-role/xxx/USER1", "arn:aws:sts::SLJFLSDKFJLSJDKF:assumed-role/xxx/USER2" ]
    },
    "Action" : "secretsmanager:*",
    "Resource" : "*"
  }]
}

When a different user tried to do a put-secret-value from aws CLI targeting the above resource, it worked and the above policy didn't stop them. My understanding from the AWS doc above is:

  1. USER2 will have an ALLOW if the role XXX has explicitly allowed secrets manager operations.

Is this assumption correct ? If so, how can I block everyone but certain individuals?

Regards,

2

There are 2 best solutions below

0
On

I think I would need to do NotPrincipal with DENY as mentioned in the docs

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_notprincipal.html

0
On

When accessing a resource within the same account, if either the resource policy explicitly grants access or the IAM user/role policy explicitly grants access, access is granted.

When using resource policies for cross account access, both the user/role IAM policy and the resource policy must grant access.

In addition, if there is a DENY statement anywhere (IAM or resource policy) access is denied. If access is not explicitly granted anywhere it is denied by default (local account or cross account).

You did not give the details of if users are in the same account or different accounts, but it sounds like they are in the same account. If a user is in the same account either they must not be granted access in their IAM policy, or there must be an explicit deny statement in the resource policy. You can also change your policy to a deny in conjunction with a not principal declaration. Then only the allowed principals can access the secret as long as their IAM user/role policy allows it.