Back in December, it was announced to deprecate the pod security policy (PSP) in Kubernetes version 1.21 and to remove the API completely at version 1.25. This decision could leave many Kubernetes users at risk of being exposed to various exploits. In the meantime, stronger alternatives have emerged in the form of Open Policy Agent and Kyverno. Each of them brings its own strengths and weaknesses. Both of these projects are viable replacements for PSPs, they are vastly more capable than simply acting on Pods alone--they are full Kubernetes policy engines. Let's have a look together to figure out which one fits your requirements.
4. Kubernetes configurations are complex the more
people are in the pipeline
External tools like Helm can not ensure env specific
configurations
Admission controllers to the rescue - validate and
mutate
8. Built - in admission controller
Early Feature of Kubernetes since 1.3 Beta-quality
since 1.8
Restrict Pods from specifying security sensitive
properties
9. How it looks like
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: example
spec:
privileged: false # Don't allow privileged pods!
...
13. Alpha in Kubernetes 1.22
Uses Pod Security Standards
Pod security restrictions are applied at namespace level
14. Three runmodes
- enforce
- Policy violations will reject the pod
- Pod is not created
- audit
- Policy violations will be tracked in audit log
- Pod is created
- warn
- Will triger only user facing warning.
- Pod is created
15. Three standards
- Privileged
- Unrestricted policy, providing the widest possible level of
permissions. This policy allows for known privilege
escalations.
- Baseline
- Minimally restrictive policy which prevents known
privilege escalations. Allows the default (minimally
specified) Pod configuration.
- Restricted
- Heavily restricted policy, following current Pod
hardening best practices.
18. O(pen) P(olicy) A(gent) - Gatekeeper
CNCF Status: Graduated (OPA)
Sub Project of general-purpose policy engine OPA
OPA unifies policy enforcement across the stack
Uses it’s own declarative language called Rego
Uses libraries
19. O(pen) P(olicy) A(gent) - Gatekeeper
“Govern”
Designed for Kubernetes
Uses Kubernetes Resources patterns and language patterns
Easy to adapt for Kubernetes Users
spec:
targets:
- target: admission.k8s.gatekeeper.sh
rego: |
package k8spspprivileged
violation[{"msg": msg, "details": {}}] {
c := input_containers[_]
c.securityContext.privileged
msg := sprintf("Privileged container is not allowed:
%v, securityContext: %v", [c.name, c.securityContext])
}
input_containers[c] {
c := input.review.object.spec.containers[_]
}
input_containers[c] {
c := input.review.object.spec.initContainers[_]
}
20. O(pen) P(olicy) A(gent) - Gatekeeper
“Govern”
Designed for Kubernetes
Uses Kubernetes Resources patterns and language patterns
Easy to adapt for Kubernetes Users
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPPrivilegedContainer
metadata:
name: psp-privileged-container
spec:
enforcementAction: dryrun
match:
kinds:
- apiGroups: [""]
kinds: ["Pod"]
26. Gatekeeper Kyverno
PRO:
Express very complex policies
OPA can be used throughout the whole
Stack
Big community
CONS:
New programming language
Mutation state not optimal
Multiple docs required to implement
Hard to read
PRO:
Kubernetes Native
Solid mutation
Quick time to value and high degree of
flexibility
CONS:
Lack of programming language may
prevent complex policies
Small community, younger
27. TL;DL;
If you do not use highly complex policies, Gatekeeper
gives you no advantage.
If you're looking for a single policy engine to in
Kubernetes and other systems, Kyverno is not for
you.
