Introduction
This is an introductory blog on Cloud Native Computing Foundation's or CNCF’s incubating project called Kyverno (greek word which means ‘Govern’). In this blog, we will learn what Kyverno is and how we can leverage it in our Kubernetes cluster to ensure the security and governs of our application deployments.
Authorization in Kubernetes
Before heading to Kyverno, just a quick refreshment on how the authorization (or AuthZ) works internally in Kubernetes.
If you are a Kubernetes administrator then you can decide and customize different authorization modes in Kube API Server configuration. It is AlwaysAllow as shown below ( — authorization-mode=AlwaysAllow
) however we can always change it to a different mode like AlwaysDeny, Node Authorizer, ABAC (attribute based), RBAC or WebHook. You can read more about each modes here but we are interested with the mode as WebHook where the authorization works with the help of the third-party popular engines like Kyverno or OPA (Open Policy Agent).
An Admission Controller is the most critical module in Kubernetes that decides how an incoming request from a user/machine is validated before it grants the permission. Not just validation, the Admission Controller is also useful to implement the better security measures to protect the cluster.
The Admission Controller performs ValidatingAdmissionWebHook and MutatingAdmissionWebhook.
Following is the flow when Kyverno is used in the cluster:-
During these(Mutating/Validating Admission) phases of Admission Controller, we can consult the incoming request with the third-party policy enforcement engines like Kyverno to actually perform the mutation or validation based on the rules (or policies) defined.
Kyverno Overview
Kyverno is a Kubernetes-native policy engine designed to validate, mutate, and generate configurations for Kubernetes resources. Unlike the other popular enforcement engines like OPA, you do not need to learn a different language like Rego to write the policies. You can define the policies (as Code) natively just like another Kubernetes resources in YAML format.
Kyverno operates as an admission controller, enforcing custom policies when a resource is created, updated, or deleted. You can use Kyverno to enforce security best practices, manage resource quotas, apply custom validation rules, or even automate Kubernetes operations.
Architecture
Kyverno Policies and Rules
A policy in Kyverno is a set of rule(s) where each rule consists of a match declaration with an optional exclude declaration and only one of validate, mutate, generate or verifyImages as child declarations, as shown below:-
A Kyverno Policy can be applied at cluster level (with kind as ClusterPolicy
) or a namespace level (with kind as Policy
). Once a policy has been applied then Kyverno enforces the best practices ensuring the governance in the cluster during the application deployments.
Application and Testing of Kyverno
This sample Kyverno policy is a cluster level policy (as the kind is ClusterPolicy
) which ensures that all the deployments created in the cluster will be tagged appropriately with the specific label, app. And if not then it throws an appropriate error message because validationFailureAction=Enforce
Note, when validationFailureAction=Audit
then Kyverno only warns but not fails the deployment.
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: enforce-app-deployment-label
spec:
validationFailureAction: Enforce
rules:
- name: check-for-label
match:
resources:
kinds:
- Deployment
validate:
message: "You must have the label, 'app' for all deployments."
pattern:
metadata:
labels:
app: "?*"
This is just one simple example however you can create complex policies like image pull from authorized source, minimum number of replica count, no latest tag on images, etc. as required, refer to doc for more details.
Applying the Policy
To apply this policy, you need to:
- First install the Kyverno in your Kubernetes cluster. Your best friend here is the official documentation for installation, head towards this link
- Apply the policy using kubectl
kubectl apply -f enforce-app-deployment-label.yaml
- Verify if the Kyverno cluster policy has been applied successfully or not
~ » kubectl get clusterpolicy
NAME ADMISSION BACKGROUND VALIDATE ACTION READY AGE MESSAGE
enforce-app-deployment-label true true Enforce True 107s Ready
Testing the Policy
Let us now test the policy by creating a Deployment without the required label:-
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app-deploy
spec:
replicas: 1
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- image: vinod827/myawesomeapp:3.0
name: my-simple-app
When you try to creating it, the Kube API server will reject the request with an error message because it is missing the required app label:
~ » kubectl create -f deploy.yaml
Error from server: error when creating "deploy.yaml": admission webhook "validate.kyverno.svc-fail" denied the request:
resource Deployment/default/my-app-deploy was blocked due to the following policies
enforce-app-deployment-label:
check-for-label: 'validation error: You must have the label, ''app'' for all deployments.
rule check-for-label failed at path /metadata/labels/'
Conclusion
By using Kyverno for Webhook based admission control, the Kubernetes administrators can easily define and enforce custom policies on Kubernetes resources. It offers an intuitive, Kubernetes-native approach to managing policies like label enforcement, resource validation, and security policies, all while simplifying governance in cloud-native environments.
References
https://kubernetes.io/docs/reference/access-authn-authz/authorization/
https://kyverno.io/docs/installation/
Top comments (0)