0

I want all roles of my AWS account having a specific pattern to be able to access a Secrets Manager secret. I know I can use Condition block and wildcard matching for that.

However, the Principal field is required in a resource policy.

Will the following policy restrict access to just the roles matching the pattern?

{
  "Statement": [
    {
      "Action": [
        "secretsmanager:UpdateSecret",
        "secretsmanager:GetSecretValue"
      ],
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": "arn:aws:iam::12345678910:role/my_role_*"
        }
      },
      "Principal": { "AWS": "arn:aws:iam::12345678910:root" },
      "Effect": "Allow",
      "Resource": "arn:aws:secretsmanager:us-east-1:12345678910:secret:some-secret-1234",
      "Sid": "rp1"
    }
  ],
  "Version": "2012-10-17"
}
pkaramol
  • 16,451
  • 43
  • 149
  • 324
  • As per this one it will work https://stackoverflow.com/questions/53429229/is-it-possible-to-specify-a-pattern-for-an-aws-role-trust-relationship. You can also solve it with IAM User or Role tags to control that. aws:PrincipalTag can be used to create IAM policy statements. https://docs.aws.amazon.com/IAM/latest/UserGuide/access_iam-tags.html – Vikram S Jan 16 '23 at 13:25

1 Answers1

0

Use the wildcard "All Principal": {"AWS": "*"}. The combination of a same-account Account Principal + wildcard condition works in role *trust* policies1 but apparently not in *resource* policies2.

The IAM docs say:

You can specify the role principal as the principal in a resource-based policy or create a broad-permission policy [with a wildcard Principal] that uses the aws:PrincipalArn condition key.

Because the condition contains the account number, the All Principal is no more permissive than the Account Principal would be. Also, because the policy is always tied to a specific secret resource, the wildcard "*" Resoure is no more permissive than the secret name. Finally, while an ArnLike condition is not always equivalent to StringLike, it is identical in this case.

{
  "Version" : "2012-10-17",
  "Statement" : [ {
    "Effect" : "Allow",
    "Principal" : {  "AWS" : "*" },
    "Action" : [ "secretsmanager:DescribeSecret", "secretsmanager:GetSecretValue" ],
    "Resource" : "arn:aws:secretsmanager:us-east-1:12345678910:secret:some-secret-1234",
    "Condition" : {
      "ArnLike" : {
        "aws:PrincipalArn" : "arn:aws:iam::12345678910:role/my_role_*"
      }
    }
  } ]
}

  1. See the wildcard permissions section of the AWS blog post How to use trust policies with IAM roles for a trust policy example.

  2. Error using a Lambda role + secrets manager resource policy with a same-account Account Principal: ...no identity-based policy allows the secretsmanager:GetSecretValue action.

fedonev
  • 20,327
  • 2
  • 25
  • 34
  • I have tested [this](https://stackoverflow.com/questions/75143142/condition-in-aws-resource-policy-not-allowing-lambda-to-access-secrets-manager-s) and it does not seem to be working – pkaramol Jan 17 '23 at 07:53
  • @pkaramol My answer works as documented for me. Double check your Role and Secret ID ARN spellings. Ensure your Secret ARN has the right 6 random digits appended. Consider debugging with wildcards instead of ARNs to prove the principle. Then narrow. – fedonev Jan 17 '23 at 08:51
  • It works without any explicit identity policy attached on the `lambda`, right? just with the above resource policy? – pkaramol Jan 17 '23 at 09:24
  • @pkaramol ;) Correct - only logging permissions in the role's identity policy. As expected, if I \*deliberately mis-spell\* the Role or Secret ARN in the resource policy, I get the dreaded `no identity-based policy allows` error. – fedonev Jan 17 '23 at 10:04