Policy Management with Kyverno in Thalassa Cloud Kubernetes

Kyverno is a Kubernetes-native policy engine that enables you to define and enforce security, compliance, and configuration policies directly as Kubernetes resources using familiar YAML syntax. By installing Kyverno in your Thalassa Cloud Kubernetes clusters, you can automatically validate, mutate, or generate resources to ensure your clusters consistently meet organizational standards and regulatory requirements.

Kyverno operates as a dynamic admission controller that intercepts API requests before resources are created or updated. This allows Kyverno to enforce policies at admission time—such as validating configurations, modifying resources to conform to policies, or generating additional resources based on cluster activity. Instead of introducing a new language or toolchain, Kyverno lets you write policies as standard Kubernetes CustomResourceDefinitions (CRDs), so you can create, edit, and manage your policies using kubectl and store them in Git for version control—just like any other cluster configuration.

Kyverno policies fall into three categories:

• Validate policies check incoming resources against custom rules and reject any that do not comply—for example, enforcing the presence of required labels, blocking privileged containers, or ensuring resource limits are set.
• Mutate policies automatically modify resources to bring them in line with best practices, such as adding missing labels, applying default resource requests and limits, or injecting sidecar containers as needed.
• Generate policies create additional resources (like NetworkPolicies or ConfigMaps) automatically in response to the creation or modification of other resources.

Prerequisites

• Before installing Kyverno, ensure you have a running Kubernetes cluster in Thalassa Cloud. If you don’t have one yet, see the Getting Started guide for instructions on creating your first cluster.
• You’ll also need cluster access configured using kubectl. Use tcloud kubernetes connect to configure access, or set up kubeconfig manually. You’ll need cluster administrator permissions to install Kyverno, as it requires creating cluster-level resources.
• Finally, ensure your cluster has sufficient resources. Kyverno is lightweight, but it needs some CPU and memory to run. A small cluster with a few nodes should be sufficient for most use cases.

Installing Kyverno

The easiest way to install Kyverno is using Helm, which is the recommended installation method. Kyverno provides an official Helm chart that handles all the necessary components.

First, add the Kyverno Helm repository:

helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update

Install Kyverno using Helm:

helm install kyverno kyverno/kyverno -n kyverno --create-namespace

This installs Kyverno in the kyverno namespace. The installation includes the Kyverno admission controller and all necessary CRDs for defining policies.

Verify that Kyverno is running:

kubectl get pods -n kyverno

You should see Kyverno pods running. Check their status:

kubectl get pods -n kyverno
kubectl logs -n kyverno -l app.kubernetes.io/name=kyverno

The logs should show that Kyverno is running and ready to process policies. If there are any errors, review the logs to identify the issue.

Verify that the Kyverno CRDs are installed:

kubectl get crd | grep kyverno

You should see several CRDs related to Kyverno policies, including clusterpolicies.kyverno.io and policies.kyverno.io.

Creating Your First Policy

With Kyverno installed, you can create your first policy. Let’s start with a simple validate policy that requires all pods to have resource limits defined. This is a common security best practice that prevents resource exhaustion.

Create a ClusterPolicy (which applies cluster-wide):

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resource-limits
spec:
  validationFailureAction: enforce
  rules:
  - name: check-resource-limits
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "All containers must have CPU and memory limits"
      pattern:
        spec:
          containers:
          - name: "*"
            resources:
              limits:
                memory: "?*"
                cpu: "?*"

Apply this policy:

kubectl apply -f require-resource-limits.yaml

This policy uses Kyverno’s pattern matching to validate that all pods have CPU and memory limits defined. The validationFailureAction: enforce means that pods without limits will be rejected. If you set it to audit, Kyverno would allow the pods but log violations.

Test the policy by trying to create a pod without resource limits:

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: nginx
    image: nginx:1.25

Try to create this pod:

kubectl apply -f test-pod.yaml

Kyverno should reject this pod because it doesn’t have resource limits. You’ll see an error message indicating that the policy validation failed.

Now create a pod with resource limits:

apiVersion: v1
kind: Pod
metadata:
  name: test-pod-with-limits
spec:
  containers:
  - name: nginx
    image: nginx:1.25
    resources:
      limits:
        memory: "128Mi"
        cpu: "100m"

This pod should be created successfully because it meets the policy requirements.

Common Policy Examples

Here are several common policies that are useful for securing and standardizing Kubernetes clusters. These policies demonstrate different Kyverno capabilities and can be adapted for your specific needs. For more policy examples and templates, see the Kyverno policy library.

Network Policy Generation

Kyverno can automatically generate NetworkPolicies when namespaces are created, working with Thalassa Cloud’s Cilium networking. For more information about network policies, see the Network Policies documentation:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: generate-network-policy
spec:
  rules:
  - name: default-deny
    match:
      resources:
        kinds:
        - Namespace
    generate:
      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      name: default-deny
      namespace: "{{request.object.metadata.name}}"
      synchronize: true
      data:
        spec:
          podSelector: {}
          policyTypes:
          - Ingress
          - Egress

This policy automatically creates a default-deny NetworkPolicy for each new namespace, ensuring that network traffic is restricted by default. You can then add more permissive policies as needed.

Best Practices

Following best practices helps you manage policies effectively and maintain secure, compliant clusters.

• Test policies thoroughly: Before enforcing policies in production, test them in development or staging environments. Create test resources that should pass and fail validation to ensure policies work as expected.

• Version control your policies: Store policies in Git alongside your other Kubernetes configurations. This provides version history, enables code review, and makes it easy to roll back policy changes if needed.

For best practices and policy examples, see the official Kyverno documentation and the Kyverno policy library.

References and Further Reading

• Kyverno Official Documentation: guides on installation, configuration, and advanced policy usage.
• Kyverno Policy Library: Curated examples and reusable policy templates for common use cases.