Add context parameter and PermissionBoundary aspect #22745
Comments
For the implementation, there are two components to "applying" the permissions boundary.
The first is "applying" the permissions boundary to a construct scope. For this I've used context since context has built in resolution up the tree. For example, you could theoretically do something like the below.
```ts
// apply at the app scope
const app = new App({
context: {
[PERMISSIONS_BOUNDARY_CONTEXT_KEY]: {
name: 'app-level-pb',
},
},
});
// apply different value at this stage
const prodStage = new Stage(app, 'Stage', {
permissionsBoundary: PermissionsBoundary.fromName('stage-pb'),
});
const stack = new Stack(prodStage, 'Stack', {
permissionsBoundary: PermissionsBoundary.fromName('stack-level-pb'),
});
```
While the above is possible, the most likely scenario is that you would apply a permission boundary at the `App`, `Stage` or `Stack` level. Stages/Stacks correspond to AWS environments (account + region) and so they would most likely also map to bootstrap environments. Because of this I've added parameters a new `permissionsBoundary` property to both the `Stage` & `Stack` props to make it easier to configure.
The second aspect to "applying" the boundary is actually attaching the permissions boundary to each IAM Role & User that is created. For this I add an Aspect to every `Stack` that has the permissions boundary context. This aspect will attach the permissions boundary to the Role or User.
closes #22745
----
### All Submissions:
* [x] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md)
### Adding new Unconventional Dependencies:
* [ ] This PR adds new unconventional dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md/#adding-new-unconventional-dependencies)
### New Features
* [x] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/main/INTEGRATION_TESTS.md)?
* [x] Did you use `yarn integ` to deploy the infrastructure and generate the snapshot (i.e. `yarn integ` without `--dry-run`)?
*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
|
Hi @corymhall I'm following the above setup but the deployment (cdk deploy) does not work. e.g., Error: MyTask/TaskRole (MyTaskTaskRole560858C4) Encountered a permissions error performing a tagging operation, please add required tag permissions. See https://repost.aws/knowledge-center/cloudformation-tagging-permission-error for how to resolve. Resource handler returned message: "User: arn:aws:sts::xxx:assumed-role/cdk-hnb659fds-cfn-exec-role-xx-eu-central-1/AWSCloudFormation is not authorized to perform: iam:CreateRole on resource: arn:aws:iam::xxx:role/SqsFargateServiceStack-MyTaskTaskRole560858C4-CUjtntvC38J4 with an explicit deny in a permissions boundary (Service: Iam, Status Code: 403, Request ID: 52393d51-805e-4bee-86d8-a49072c0f03e)" Thanks |
Add a new context variable that the user can set with the permission boundary name. We can then use that value to apply the permission boundary (using Aspects).
cdk.json
{ "context": { "@aws-cdk/core:permissionBoundaryName": "my-permission-boundary" } }Apply the permission boundary somewhere based on a context variable. This should take stages into account. For example, the user may need to apply different permissions boundaries based on the stage.
The text was updated successfully, but these errors were encountered: