-
Notifications
You must be signed in to change notification settings - Fork 303
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
Proposal: fine-grained policy-excludes #591
Comments
Contextual exclusions will greatly improve quality of policies. Thank you for kickstarting this and for the PoC PR! I would like to offer one additional viewpoint, if I may... A lot of the cumbersomeness with contextual exclusions – is passing the context. The actual What if we never have to pass on the context, and the exclusion can be done inline – right where the context is? i.e. What if exclusion is not a separate construct, but a function. For example:
Would be awesome if the
|
Hi @rdsubhas, Thanks for the detailed feedback! I appreciate it. I see the appeal of this solution, as you say having the full context makes it considerably easier to make sense of what is going on & help reduce the chance of an error. My proposal definitely includes additional complexity & possibility for misconfiguration (Although the current exclude functionality still has this issue). One issue I see with embedding the deny_root[result] {
input.kind == "Deployment"
c = input.spec.template.spec.containers[_]
not c.securityContext.runAsNonRoot
result := sprintf("container %s in deployment %s doesn't set runAsNonRoot", [c.name, input.metadata.name])
exclude(c.name == "host-agent")
} If department B would like to re-use the above, it would need to be copied & pasted (in the case they would like to extend/remove the exclusions. You do bring forward a good point though & I think as rego policies get more complicated more engineering practices will need to be applied (such as refactoring most functionality into functions). ## ------ Helpers -----
deployment_containers[container] {
container := input.spec.template.spec.containers[_]
}
is_deployment {
input.kind == "Deployment"
}
deployment_containers_root[result] {
container := deployment_containers[_]
# conditions
not c.securityContext.runAsNonRoot
result := {
"msg": sprintf("container %s in deployment %s doesn't set runAsNonRoot", [container.name, input.metadata.name]),
"meta": container
}
}
# ----- Policy ---------
deny_root[result] {
is_deployment
msg := deployment_containers_root
result := msg[_]
}
exclude_root[result] {
value := deny_root[_]
input.metadata.name == "my-dep"
value.meta.name == "host-agent"
result := value
} It's always going to be difficult to add exclusions to certain policies. Let me know what you think of using the output of the |
This is a proposal for implementing fine-grained excludes.
This proposal adds a new
excludes
type to the conftest tool which allows for more fine-grained exclusion of policies. I have also attached a sample implementation (linked here) that can already be played with & serve as a reference.Issue
Currently conftest is limited to only being able to 'disable' a policy rule over a whole file. This means that it's not possible to have a policy be applied to a subset of elements within a file, it's all or nothing.
This is naturally an issue, especially for projects which are wanting to adopt conftest incrementally into an already existing project. In this case it is difficult to apply a fine-grained policy enforcement which blocks newly added policy-violating definitions into an already existing file.
While there are workarounds, it is difficult to use them and requires modifying the
deny
rules directly (meaning they won't show up as being explicit exceptions).Proposal
The linked Proposal includes an extension to conftest with a new keyword
exclude
. This can be used to attach specific exclusions to a policy. Below is a quick sample:First off, the current behaviour is preserved, so no policies will be affected by this change.
There are a few changes to how we need to write our rego.
deny_root
&exclude_root
).With these changes, we are able to write more flexible exclusion rules with as much flexibility in our exclusion logic as we would like.
Actions
References
The text was updated successfully, but these errors were encountered: