(secretsmanager ): grant_read/grant_write on secret throws KMS key error on role from same account

[mooiweer]

Giving a preexisting role read/write access to a secret using the grant_read/grant_write method on a secret throws the error:
"KMS Key must be provided for cross account access to Secret"
Even though both secret and role are from the same AWS account.

Reproduction Steps

Use an existing role and create a new secret
Give it read/write access

from aws_cdk import (
    aws_iam as iam,
    aws_secretsmanager as secretsmanager,
    core
)

class Stack(core.Stack):
  role = iam.Role.from_role_arn(self, "role", <existing iam role>)
  
  secret = secretsmanager.Secret(
      scope=self,
      id="secret-id",
      description='secret desc'
  )
  secret.grant_read(role)
  secret.grant_write(role)


app = core.App()
Stack(app, "SecretKMSError")
app.synth()

What did you expect to happen?

I expect the created secret to be created with read and write rights added to the existing role.

What actually happened?

CDK deploy throws an error:
KMS Key must be provided for cross account access to Secret
Even though both the (pre-existing) and the secret are on the same AWS account

Environment

• CDK CLI Version : 1.111.0
• Framework Version: 1.111.0
• Node.js Version: v12.20.1
• OS : Windows 10
• Language (Version): Python (3.8)

Other

This worked before version 1.111.0

Workaround:

role.add_to_policy(iam.PolicyStatement(effect=iam.Effect.ALLOW, actions=['secretsmanager:PutSecretValue', 'secretsmanager:UpdateSecret', 'secretsmanager:GetSecretValue', 'secretsmanager:DescribeSecret'], resources=[secret._arn_for_policies]))

I think it was introduced by this commit:
ea40cfe

---

This is 🐛 Bug Report

[madeline-k]

Hi @mooiweer , I am not able to reproduce this error if I use a Role.fromRoleArn role that is inside the same account as my stack environment.

However, I can reproduce the error if I supply an ARN such as: "arn:aws:iam::123456789012:role/MyRole-AJJHDSKSDF" where the account id inside the ARN does not match the account id of my stack's environment.

Can you please verify that the ARN of the role is in fact in the same account that your stack environment is using?

[nwouda]

I'm experiencing the same issue. In my case the ARN of the role is stored in the parameter store. This is indeed introduced in version 1.111.0. The ARN of the role is the same as the account deployed to, but my best bet is that CDK can't tell because it doesn't actively pull it from SSM.

[madeline-k]

Thanks for the extra detail, @nwouda. This seems to be a case where the CDK is performing validation in some cases where we can't actually know the value, like referencing an ARN in SSM. And agreed this is probably a regression introduced in 1.111.0.

Despite it being a regression, I am going to triage as a p2 since customers have a workaround which is to explicitly add to the role's policy instead of using the grant functions. p2 means that the CDK team won't be able to prioritize this right now, but we always welcome contributions!

[madeline-k]

@nwouda and @mooiweer if either of you are interesting in fixing this yourself, please take a look at the contributing guide.

[jrruethe]

I am affected by this, and I believe the issue was introduced with this commit:
#14834

[kaiz-io]

This can be closed was fixed in https://github.com/aws/aws-cdk/releases/tag/v1.140.0

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.