Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(dynamodb): grant calls no longer working when passed a ManagedPolicy #32795

Open
1 task done
wilhen01 opened this issue Jan 8, 2025 · 4 comments
Open
1 task done
Labels
@aws-cdk/aws-dynamodb Related to Amazon DynamoDB bug This issue is a bug. p3 potential-regression Marking this issue as a potential regression to be checked by team member

Comments

@wilhen01
Copy link
Contributor

wilhen01 commented Jan 8, 2025

Describe the bug

Previously, it's been possible to use .grant functions on dynamoDB tables and pass them a ManagedPolicy (which is allowed by the type system since ManagedPolicy implements IGrantable).

Under 2.174.0, that results in an error:

Cannot use a ManagedPolicy as the 'Principal' or 'NotPrincipal' in an IAM Policy.

This is a change in behaviour, and it's also inconsistent with e.g. S3 where it's still possible to call bucket.grantReadWrite(managedPolicy);

Regression Issue

  • Select this option if this issue appears to be a regression.

Last Known Working CDK Version

2.131.0

Expected Behavior

.grant functions for dynamo tables work when passed a ManagedPolicy and add the appropriate policy statements.

Current Behavior

Error thrown: Cannot use a ManagedPolicy as the 'Principal' or 'NotPrincipal' in an IAM Policy

Reproduction Steps

const table = TableV2.fromTableArn(
  this,
  'Table',
  arnForTable,
);
table.grantReadWriteData(managedPolicy);

Error is visible in CDK unit tests which verify the managed policy composition.

Possible Solution

No response

Additional Information/Context

I'm not sure if the new behaviour is correct in that a ManagedPolicy is not in fact a Principal, and hence the previous behaviour shouldn't have been allowed, but it should be consistent and obvious from documentation where you can and can't use the convenience grant functions. At present they work in this scenario for other library areas e.g. S3.

CDK CLI Version

2.174.0

Framework Version

No response

Node.js Version

18

OS

Mac OS

Language

TypeScript

Language Version

5.x

Other information

No response

@wilhen01 wilhen01 added bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. labels Jan 8, 2025
@github-actions github-actions bot added @aws-cdk/aws-dynamodb Related to Amazon DynamoDB potential-regression Marking this issue as a potential regression to be checked by team member labels Jan 8, 2025
@pahud pahud self-assigned this Jan 8, 2025
@pahud pahud added the investigating This issue is being investigated and/or work is in progress to resolve the issue. label Jan 8, 2025
@pahud
Copy link
Contributor

pahud commented Jan 8, 2025

Can you show me how do you define managedPolicy?

if you use fromXxx() method, you get IManagedPolicy rather than ManagedPolicy and IManagedPolicy does not implement IGrantable.

@pahud pahud added the response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 7 days. label Jan 8, 2025
@pahud pahud removed their assignment Jan 8, 2025
@pahud pahud added p3 and removed needs-triage This issue or PR still needs to be triaged. investigating This issue is being investigated and/or work is in progress to resolve the issue. labels Jan 8, 2025
@wilhen01
Copy link
Contributor Author

wilhen01 commented Jan 8, 2025

@pahud it's defined within the same CDK stack I'm using the .grant calls in via new ManagedPolicy. I'm not doing any casts on it in order to pass it into the grant calls either, so it clearly implements IGrantable. The code looks roughly like:

const policy = new ManagedPolicy(this, 'StandardPolicy', {
      managedPolicyName: 'StandardPolicy',
      description:
        'Grants team members permissions to perform BAU tasks such as lambda invocation and reading secrets.',
});

...

const table = TableV2.fromTableArn(
  this,
  'Table',
  arnForTable,
);
table.grantReadWriteData(policy);

There are a number of other calls in the stack to add other statements to the policy (many of which are constructed manually via new PolicyStatement rather than using .grant convenience functions) but you get the picture.

@pahud
Copy link
Contributor

pahud commented Jan 8, 2025

Yes I am seeing

Error: Cannot use a ManagedPolicy 'DummyStack2/StandardPolicy' as the 'Principal' or 'NotPrincipal' in an IAM Policy
at ManagedPolicyGrantPrincipal.get policyFragment [as policyFragment] (/***/node_modules/aws-cdk-lib/aws-iam/lib/managed-policy.js:1:5464)

The error is thrown from

throw new Error(`Cannot use a ManagedPolicy '${this._managedPolicy.node.path}' as the 'Principal' or 'NotPrincipal' in an IAM Policy`);

Reason:

// This property is referenced to add policy statements as a resource-based policy.
// We should fail because a managed policy cannot be used as a principal of a policy document.
// cf. https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#Principal_specifying

which was fixed in this PR.

so it should be a bug fix not a breaking change.

@wilhen01
Copy link
Contributor Author

wilhen01 commented Jan 8, 2025

I don't think that PR is the root cause of this bug? If I'm reading it correctly that PR adds IGrantable to ManagedPolicy, but my code was working as of 2.131.0 and ManagedPolicy implements IGrantable in that version of the library so I think something else has changed between 2.131.0 and the current version to cause this issue...

@github-actions github-actions bot removed the response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 7 days. label Jan 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@aws-cdk/aws-dynamodb Related to Amazon DynamoDB bug This issue is a bug. p3 potential-regression Marking this issue as a potential regression to be checked by team member
Projects
None yet
Development

No branches or pull requests

2 participants