-
Notifications
You must be signed in to change notification settings - Fork 180
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
[RFC] Property and Filtering Enhancements #115
[RFC] Property and Filtering Enhancements #115
Conversation
rfcs/rfc-113.md
Outdated
%encryption = BucketEncryption.ServerSideEncryptionConfiguration.*.ServerSideEncryptionByDefault | ||
%encryption.property == "VALUE" | ||
$encryption.otherProperty IN ["ALLOWED", "VALUES"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
think I prefer the block-syntax discussed in #111 so context can't be split across different parts of rulesets
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a lot of this was trying to keep the block evaluations out of this PR as to not be adding those changes to the proposal as well
rfcs/rfc-113.md
Outdated
Parameters.BucketName.Type == "String" # conforms to a certain type | ||
Parameters.BucketName.AllowedValues.* == /\w*bucket\w*/ # make sure values are expected | ||
|
||
Resources.*[Type == "AWS::S3::Bucket"].Properties.BucketName == { "Ref": "BucketName"} # ensure bucket name is in allowed values of parameters |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
similar to #111 (comment), I'd really rather not have to specify Resources
and Properties
in almost every rule, so I'd want something like the block-syntax if they're both going to be required going forward
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah this was done more to show the functionality of the changes without mixing the two proposals. ideally if these are both merged you could choose how to write these checks: using blocks or some sort of filtering on the top level keys like this
Co-authored-by: Pat Myron <PatMyron@users.noreply.github.com>
Co-authored-by: Pat Myron <PatMyron@users.noreply.github.com>
All issues linked in this RFC PR have been addressed. I am merging this RFC to the Guard1.0 branch. |
Issue #, if available: #107, #105, #99,#98, #94, #86, #5, #3
Description of changes: Attached is a draft RFC for improvements related to extending key/value access in template to more than just the properties block of a resource type and allowing for more complex filtering of values in collections in templates. Will refine this a bit more next week but want to circulate for now in a draft state. This builds off #111's proposed type block enhancements in some examples.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.