We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
Hi all, I'm working on some rego rules for RAM and I have some use cases where the usage of a single
deny [{}] {}, as recommended in current rego rules guide
deny [{}] {}
https://github.com/GoogleCloudPlatform/policy-library/blob/main/docs/constraint_template_authoring.md#write-rego-rule-for-constraint-template
could lead to some complex code.
So I'm wondering why it is not possible to use something like
allow {} deny [{ msg1 }] {logic} deny [{ msg2 }] {logic}
and so on. As this should be a valid rego approach, is there underlying issue that could prevent this approach? Thanks.
The text was updated successfully, but these errors were encountered:
No branches or pull requests
Hi all, I'm working on some rego rules for RAM and I have some use cases where the usage of a single
deny [{}] {}
, as recommended in current rego rules guidehttps://github.com/GoogleCloudPlatform/policy-library/blob/main/docs/constraint_template_authoring.md#write-rego-rule-for-constraint-template
could lead to some complex code.
So I'm wondering why it is not possible to use something like
and so on.
As this should be a valid rego approach, is there underlying issue that could prevent this approach?
Thanks.
The text was updated successfully, but these errors were encountered: