-
Notifications
You must be signed in to change notification settings - Fork 4k
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
fix(ec2): Volume grants have an overly complicated API #9115
Conversation
Resolves: #9114 |
Thank you for contributing! Your pull request will be updated from master 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 master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
I designed & wrote the code for the L2 Volume construct. My design for the `grantAttachVolumeByResourceTag()` and `grantDetachVolumeByResourceTag()` is flawed. Those functions have three design requirements: 1) To allow an instance to attach a Volume to itself; 2) To allow an instance to attach multiple, different, volumes; and 3) To allow the same volume to be attached to different instances via separate grants without clobbering other grants. Since the implementation mechanism for this is a `ResourceTag` condition on the policy, the later two requirements mean that we must have both a unique tag key and a unique tag value for each separate permission grant (i.e. separate call to the volume's grant function). The original design had the tag key being derived from only the volume, the tag value from only the instance(s), and allowed for overriding the tag key via a parameter to allow for the same volume to attach to multiple instances over separate grants. In hindsight, we should be deriving both the resource tag and value from the combination of the instance(s) and the volume's unique properties. This completely eliminates the need for the tag key override. The current design results in code like: ```ts // To be able to mount the *same* volume to multiple instances we must provide a tag suffix to the permission grant // that is unique to this particular combination of volume + mount target. function hashUniqueIds(resources: IConstruct[]): string { const md5 = crypto.createHash('md5'); resources.forEach(res => md5.update(res.node.uniqueId)); return md5.digest('hex'); } this.props.blockVolume.grantAttachVolumeByResourceTag(target.grantPrincipal, [target], hashUniqueIds([target, this.props.blockVolume])); ``` It is much more desirable for this to be simply: ```ts this.props.blockVolume.grantAttachVolumeByResourceTag(target.grantPrincipal, [target]); ``` Resolves: #9114 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
I designed & wrote the code for the L2 Volume construct. My design for the
grantAttachVolumeByResourceTag()
andgrantDetachVolumeByResourceTag()
is flawed.Those functions have three design requirements:
Since the implementation mechanism for this is a
ResourceTag
condition on the policy, the later two requirements mean that we must have both a unique tag key and a unique tag value for each separate permission grant (i.e. separate call to the volume's grant function).The original design had the tag key being derived from only the volume, the tag value from only the instance(s), and allowed for overriding the tag key via a parameter to allow for the same volume to attach to multiple instances over separate grants.
In hindsight, we should be deriving both the resource tag and value from the combination of the instance(s) and the volume's unique properties. This completely eliminates the need for the tag key override.
The current design results in code like:
It is much more desirable for this to be simply:
Resolves: #9114
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license