Note: for support questions, please first reference our documentation, then use Stackoverflow. This repository's issues are intended for feature requests and bug reports.

• I'm submitting a ...

  • 🪲 bug report
  • 🚀 feature request
  • 📚 construct library gap
  • ☎️ security issue or vulnerability => Please see policy
  • ❓ support request => Please see note at the top of this template.

• What is the current behavior?
  If the current behavior is a 🪲bug🪲: Please provide the steps to reproduce

When passing an IRole around, permissions can be added to the role under certain conditions (namely, the role must either be owned by the current application, or reside in the same account than the stack granting the additional permissions).

• What is the expected behavior (or behavior of feature suggested)?

In certain conditions, a user might want to prohibit new statements being added to a Role policy. The proposition is to offer an IRole wrapper that simply ignores attempts to add statements (either directly or through policies) to the role.

Additionally, as imported roles are a common use-case for this, it would be interesting to add an optional { ignoreNewStatements = false } parameter to the Role.from* methods.

• What is the motivation / use case for changing the behavior or adding this feature?

In certain cases, roles are created by a dedicated organization, and CDK App developers are not allowed to directly modify those. In such cases, attempts to add new statements to imported roles will likely cause in a deployment failure due to insufficient permissions.

In other cases, a user might want to ensure that permissions they hand-crafted for a given role are honored without modification.

This feature means that all places where an optional IRole is accepted, the granting behavior for both the "default role" and "user-provided role" cases can be identical, where the construct grants all necessary permissions that are derived from other parameters (example: a SageMaker training job always needs to be able to read/decrypt it's inputs, write/encrypt it's outputs, etc...).