jsPolicy provides three types of policies:
|Trigger||Requests to k8s API server||Requests to k8s API server||Changes to k8s object (Events)|
Validating policies run during a HTTP request to the Kubernetes API server. After Kubernetes performs authentication and authorization (RBAC), it runs the
Mutating policies sequentially and then runs all
Validating policies in parallel. If any of the
Validating policies calls
deny(), the request will be aborted and not persited in etcd.
Controller policies are not part of any Kubernetes API server request. Instead, they are triggered asynchronuously by
Events in your Kubernetes cluster. Every CRUD operation on any of the Kubernetes objects in your cluster creates an
Event. jsPolicy listens to these events and executes the matching
Controller policies which can perform any kind of action in response to an
Event, including also executing other CRUD operations in your cluster.
Deny vs Warn
Mutating and validating policies may also use
warn() to display warnings to client, i.e. these warnings will not impact the request itself but they are shown in the
kubectl output for example.
There are two ways to provide policy code to jsPolicy:
JsPolicyobject (see Quickstart example policy)
- Creating a
PolicyBundleobject with the same name as the corresponding
spec.bundlefield of the
If you choose the trivial option 1 and you place your policy code directly inside the
JsPolicy, the Policy Compiler of jsPolicy will detect this and automatically generate a
JsPolicyViolations objects with information about denied requests and errors during the execution of policies. These objects can be queried using
kubectl and the Kubernetes API server to set up alerting and monitoring for policy exection.