question on design: why aren't requests passed as input? about gatekeeper HOT 5 CLOSED

Why was it decided not to use the standard approach?

We're in the process of deciding how the policy library ought to be structured. It's arguable that since the input-based version is more familiar for most people, we should keep it.

The reason we started with the data-based version was that it naturally lends itself to audit queries (e.g., asking for a list of all violations, violations in a particular namespace, violations on pods, violations of some kind, etc.) It is possible to use the input-based version for audit, but it requires additional logic/code.

This policy would always fail, no matter the name of the new resource, a match would always be found....

Since the controller only asks for the violations for the resource being admitted, this is not a problem. E.g., there could be many other resources with the name ceph (of different kinds or in different namespaces) but since the controller executes the query like data.admission.deny[{"id": id, "resource": {"kind": "SomeKind", "namespace": "default", "name": "ceph"}, "resolution": r}] only the violations for that resource are computed & returned.

from gatekeeper.

I need to understand the mechanics of this a bit better, but it does feel kind of cleaner to me that data is actual current state and input is potential new state.

I haven't found the exact code for this - how does the request get removed from data, if it gets denied? Or did you mean to keep all requests in data so you could later query them? That would create a LOT of data.

In terms of the audit/query functionality, if kube-mgmt is syncing the resource type of the query then the updated state ends up in data anyway, if the admission review isn't denied. So if the intent is to, say, find out what things that already exist that would violate this policy, you can still do that. In any case the query would have to be different, as objects in a requests are inside a request object, but other k8s resources are just under kubernetes.

from gatekeeper.

@tsandall thanks. I think now it's clear to me.
I think more explanation is needed in the doc about this choice.
Also, I couldn't find examples/tutorial about the audit functionality.
How does it work?

from gatekeeper.

Thanks @raffaelespazzoli for the feedback.

All policies in the controller support 'audit' via GET '\audit' api.

Short description:
The requires kubernetes dependencies are sync (eventual consistent) by 'kube-mgmt`
The policy controller uses the same policies to query for violations in real time (when /audit endpoint is called)

There is lot of scope to enhance docs for this. Please refer to the video if that helps (also the link is added in the README for this project)
https://www.youtube.com/watch?v=1WObJiTZDHc&feature=youtu.be

from gatekeeper.

Requests are now passed as input (as of v3)

from gatekeeper.