feat(iam): apply permissions boundary to a Stage
#22913
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR should be not be merged until #22792 which adds support for creating a default permissions boundary as part of CDK bootstrap. Once that is merged we will be creating a default permissions boundary managed policy with a standard naming convention. That allows us to easily attach this default permissions boundary to applications at either the `Stage` or `Stack` level. 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.default(), }); const stack = new Stack(prodStage, 'Stack', { permissionsBoundary: PermissionsBoundary.fromName('stack-level-pb'), }); class MyConstruct extends Construct { constructor(scope: Construct, id: string) { super(scope, id); const pb = PermissionsBoundary.fromName('construct-level-pb'); pb.bind(this); } } ``` While the above is possible, the most likely scenario is that you would apply a permission boundary at the `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 by default to every `Stack`. This aspect will look for the `context` that was applied earlier for whether or not it should attach a permissions boundary to the Role or User. closes #22745
|
|
aws-cdk-automation
previously requested changes
Nov 14, 2022
aws-cdk-automation
dismissed
their stale review
✅ Updated pull request passes all PRLinter validations. Dissmissing previous PRLinter review.
Naumel
reviewed
Nov 15, 2022
packages/@aws-cdk/aws-iam/README.md
Outdated
Comment on lines
432
to
433
| This will apply the default permissions boundary created as part of CDK | ||
| bootstrap to all IAM Roles that are created within this `Stage`. |
There was a problem hiding this comment.
[note, not feedback] I've seen a lot of confusion stemming from dev experience to pipeline/ prod expectation. Should we have a bigger paragraph here or full docs on how to do development vs how to deploy?
Or it gets to be informational excess?
Naumel
approved these changes
Nov 18, 2022
Comment on lines
+480
to
+483
| (arn.includes('${Qualifier}') | ||
| || arn.includes('${AWS::AccountId}') | ||
| || arn.includes('${AWS::Region}') | ||
| || arn.includes('${AWS::Partition}'))) { |
There was a problem hiding this comment.
[neither here nor there] Easier to check than for ^\$\{[a-zA-Z0-9]+\}?
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
4 tasks
mergify bot
pushed a commit
that referenced
this pull request
Nov 23, 2022
#22744 Users can now specify in the CDK CLI a [(permissions boundary) policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) to be applied on the Execution Role and all subsequent IAM users and roles of their app. If you want to try out the feature, a good starting point is having the`--example-permissions-boundary`(or `--epb`) parameter for the `cdk botstrap`: ``` cdk boostrap --epb ``` This achieves a couple of things: a new policy will be created (if not already present) in the account being bootstrapped (`cdk-${qualifier}-permissions-boundary`) and it will be referenced in the bootstrap template. In order for the bootstrap to be successful, the credentials use must include `iam:getPolicy` and `iam:createPolicy` permissions. This works pairs with #22913, as permissions boundary needs propagation. You can inspect the policy via the console, retrieve it via aws cli or sdk and you can copy the structure to use on your own from `packages/aws-cdk/lib/api/bootstrap/bootstrap-template.yaml`: Resources.CdkBoostrapPermissionsBoundaryPolicy At this point you can edit the policy, add restrictions and see what scope would match your requirements. For non-dev work, the suggestion is to use `--custom-permissions-boundary` (or `--cpb`): ``` cdk bootstrap --cpb "custom-policy-name" ``` The policy must be created and accessible for the credentials used to perform the bootstrap. ---- ### 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 * [ ] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/main/INTEGRATION_TESTS.md)? * [ ] 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*
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
While the above is possible, the most likely scenario is that you would apply a permission boundary at the
App,StageorStacklevel. 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 newpermissionsBoundaryproperty to both theStage&Stackprops 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
Stackthat has the permissions boundary context. This aspect will attach the permissions boundary to the Role or User.closes #22745
All Submissions:
Adding new Unconventional Dependencies:
New Features
yarn integto deploy the infrastructure and generate the snapshot (i.e.yarn integwithout--dry-run)?By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license