-
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
[ec2] Fix design flaw in Volume grants by ResourceTag #9114
Labels
@aws-cdk/aws-ec2
Related to Amazon Elastic Compute Cloud
effort/small
Small work item – less than a day of effort
feature-request
A feature should be added or improved.
in-progress
This issue is being actively worked on.
p1
Comments
ddneilson
added
feature-request
A feature should be added or improved.
needs-triage
This issue or PR still needs to be triaged.
labels
Jul 16, 2020
github-actions
bot
added
the
@aws-cdk/aws-ec2
Related to Amazon Elastic Compute Cloud
label
Jul 16, 2020
ericzbeard
added
p1
and removed
needs-triage
This issue or PR still needs to be triaged.
labels
Jul 16, 2020
mergify bot
pushed a commit
that referenced
this issue
Aug 10, 2020
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*
eladb
pushed a commit
that referenced
this issue
Aug 10, 2020
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*
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
@aws-cdk/aws-ec2
Related to Amazon Elastic Compute Cloud
effort/small
Small work item – less than a day of effort
feature-request
A feature should be added or improved.
in-progress
This issue is being actively worked on.
p1
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. Put simply, this is an overly complicated design and I should never have submitted it.
Use Case
Less kludgy code in applications that use the ResourceTag-conditioned grants.
Proposed Solution
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:
Other
I have a PR prepared for this, and will be submitting it immediately after filing this ticket.
This is a 🚀 Feature Request
The text was updated successfully, but these errors were encountered: