0

Consider central_secrets_account with AWS account id XXXXXXXXXXXX that holds secrets that need to be shared with a blue_green_account YYYYYYYYYYYYY. I wish to create a cloudformation stack in blue_green_account that will access a secret in central_secrets_account.

My method is based on sts:AssumeRole chaining as follows. I have created a blue_green_role in blue_green_account that can be assumed by the local cloudformation service. The blue_green_role trust policy is

{
   "Version": "2012-10-17",
   "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
            "Service": "cloudformation.amazonaws.com"
        },
        "Action": "sts:AssumeRole"
      }
   ]
}

and its permissions policy is

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRole"
            ],
            "Resource": "arn:aws:iam::XXXXXXXXXXXX:role/cross-account-read-secret-role"
        }
    ]
}

which allows it to assume a secret-reading role that resides in the central_secrets_account.

Similarly, the cross-account-read-secret-role in central_secrets_account has a trust policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::YYYYYYYYYYYY:role/blue_green_role",
                    "arn:aws:sts::YYYYYYYYYYYY:assumed-role/blue_green_role/AWSCloudFormation"
                ]
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

and its permissions policy (which is loose, just get this going) is

    {
        "Action": [
            "secretsmanager:*"
        ],
        "Resource": "*",
        "Effect": "Allow"
    },

However, when I spin up the stack in the blue_green_account which has a dynamic reference {{resolve:secretsmanager:arn:aws:secretsmanager:eu-west-2:XXXXXXXXXXXX:secret:secret_name_zzzzzz}} in the cloudformation template, I get the following error

User: arn:aws:sts::YYYYYYYYYYYYYY:assumed-role/blue_green_role/AWSCloudFormation is not authorized to perform: secretsmanager:GetSecretValue on resource: arn:aws:secretsmanager:eu-west-2:XXXXXXXXXXXX:secret:secret_name_zzzzzz because no identity-based policy allows the secretsmanager:GetSecretValue action

I've tried many different adjustments to get this to work, but to no avail. There is another KMS permissions method but I feel the role assuming method is more simple for our use case.

rnoodle
  • 534
  • 2
  • 5
  • 21
  • Its not clear what you are doing. What exactly `${blue_green_account_id}` is supposed to be? An input parameter of your template? – Marcin Mar 16 '23 at 11:22
  • It's just the 12 digit AWS account number for the `blue_green_account`. I used variable notation to show it's association with the account. In reality this is not a variable of course. – rnoodle Mar 16 '23 at 11:25
  • @Marcin - I've removed variable notation to make it clear. – rnoodle Mar 16 '23 at 11:31
  • The error message indicates that whatever role CloudFormation runs under does not have permission to invoke `GetSecretValue`. You haven't shown anything other than trust policies, so we have no idea whether the role grants this. Cross-account access requires two things: the resource must grant permission to the prinicpal, _and_ the principal must have permissions to access the resource. – kdgregory Mar 16 '23 at 12:33
  • @kdgregory - I've shown a trust policy and a permission policy for both the `blue_green_role` and `cross-account-read-secret-role`. – rnoodle Mar 16 '23 at 12:49
  • 1
    This is a case where simply showing the entire role would have avoided confusion. It appears that you're expecting CloudFomation to know that it has to assume a role in `central_secrets_account`, and give it permission to do so. But (unless they've changed something _very_ recently) it has no way to know that it needs to assume that role. – kdgregory Mar 16 '23 at 13:40
  • 1
    When I said that "the principal must have permissions," I meant adding an `ALLOW GetSecretValue` to `blue_green_role`. – kdgregory Mar 16 '23 at 13:41
  • @kdgregory I added the `ALLOW` as you suggested, but to no avail. On your other point: cloudformation readily assumes `blue_green_role` without being told explicitly, but as you said, it doesn't know how to assume `cross-account-read-secret-role` while it is assuming `blue_green_role`... – rnoodle Mar 16 '23 at 15:09
  • I guess I wasn't clear/assumed you understood the difference between a _resource-based_ policy and an _identity-based_ policy. The secret has the former, CloudFormation has the latter. – kdgregory Mar 17 '23 at 12:23
  • I recommend reading about those two policy types in the IAM manual, try it out using the CLI from account B, and if you still don't have it working, then edit the question and show _everything_ that you're doing, not just selected pieces. – kdgregory Mar 17 '23 at 12:24
  • @kdgregory I went ahead with a resource policy on the secret and a custom KMS key-pair (for encrypting/decrypting the secret) which also has a key policy. Both the resource policy and key policy allow the various secretsmanger and external account roles (principals) to secretsmanager:GetSecretValue and kms:decrypt. This is a different method to the sts:AssumeRole approach (which I couldn't get working). – rnoodle Mar 18 '23 at 11:56

0 Answers0