Mutating policies
Mutating policies are structured in the same way as validating ones:
- They have to register
validate
andvalidate_settings
waPC functions. - The communication API used between the host and the policy is the same as that used by validating policies.
Mutating policies accept a request and can propose a mutation of the incoming
object by returning a ValidationResponse
object that looks like this:
{
"accepted": true,
"mutated_object": <object to be created>
}
The mutated_object
field contains the object the policy wants to be created in the Kubernetes cluster,
serialized to JSON.
A concrete example​
Let's assume the policy received this ValidationRequest
:
{
"settings": {},
"request": {
"operation": "CREATE",
"object": {
"apiVersion": "v1",
"kind": "Pod",
"metadata": {
"name": "security-context-demo-4"
},
"spec": {
"containers": [
{
"name": "sec-ctx-4",
"image": "gcr.io/google-samples/node-hello:1.0",
"securityContext": {
"capabilities": {
"add": ["NET_ADMIN", "SYS_TIME"]
}
}
}
]
}
}
}
}
For learning purposes we left some unimportant fields out of the request
object.
This request is generated because someone tried to create a Pod that would look like this:
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo-4
spec:
containers:
- name: sec-ctx-4
image: gcr.io/google-samples/node-hello:1.0
securityContext:
capabilities:
add:
- NET_ADMIN
- SYS_TIME
Let's assume our policy replies with the following ValidationResponse
:
{
"accepted": true,
"mutated_object": {
"apiVersion": "v1",
"kind": "Pod",
"metadata": {
"name": "security-context-demo-4"
},
"spec": {
"containers": [
{
"name": "sec-ctx-4",
"image": "gcr.io/google-samples/node-hello:1.0",
"securityContext": {
"capabilities": {
"add": [
"NET_ADMIN",
"SYS_TIME"
],
"drop": [
"BPF"
]
}
}
}
]
}
}
}
That would lead to the request being accepted, but the final Pod would look like this:
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo-4
spec:
containers:
- name: sec-ctx-4
image: gcr.io/google-samples/node-hello:1.0
securityContext:
capabilities:
add:
- NET_ADMIN
- SYS_TIME
drop:
- BPF
As you can see, the policy altered the securityContext.capabilities.drop
section of the only container declared in the Pod.
The container is now dropping the BPF
capability due to our policy.
Recap​
These are the functions a mutating policy must implement:
waPC function name | Input payload | Output payload |
---|---|---|
validate | { | { |
validate_settings | { | { |