GoogleCloudPlatform / policy-library

A library of constraint templates and sample constraints for Constraint Framework tools
Apache License 2.0
223 stars 129 forks source link

Question: managing centralised constraint exclusion #400

Closed jralmaraz closed 3 years ago

jralmaraz commented 3 years ago

Hi,

We're looking for recommendation on how to centralise managing target exclusions.

My initial idea is to have a file or variable that would have the list of projects to be excluded and use some YAML placeholder.

Can you confirm if that approach is correct and hopefully provide an example ?

Thanks!


Example, project folders to be excluded (keep some variable file so people who get exemption approval can raise a PR to just have their project added):

var: ["organizations/a/folders/b/projects/x", "organizations/a/folders/c/projects/x"]

--- In gcp_constraint_sample.yaml: ... spec: severity: high match: target: ["organizations/**"] exclude: [{{var}}]

morgante commented 3 years ago

Can you clarify the use case / what problem you're trying to solve?

In general, exclusions are for excluding a project from a particular constraint that would otherwise apply (ex. a particular project needs to publish a public bucket), not to exclude projects from all constraints. In such scenarios, they should just need to raise a PR adding it to the exclusion list in constraint.yaml.

jralmaraz commented 3 years ago

Hi @morgante , thanks for the update.

Agreed they can just raise a PR adding to the exclusion list, my idea was to simplify and having them to edit a central variables file containing the constraint ID as the key value, for example, so to avoid typos or other breaking changes in the constraints file itself, people would just update the variable file and keeping a track for approval/audit.

Is that a valid scenario ? If not, any other recommendation that this is valid is more than welcome :), otherwise, we stick with raising PRs to constraint file directly (and polish a process of tests/build of the policy library repo).

Thanks again!

morgante commented 3 years ago

Since the variable would theoretically just be mirrored into the constraint yaml, I don't think you're gaining any protection from typos. I'd recommend sticking to editing the constraint directly (and building appropriate processes around verifying that changes are valid).

jralmaraz commented 3 years ago

Sure thing, appreciate the response, cheers.