In today’s fast-moving cloud-native ecosystem, Kubernetes has become the de facto standard for container orchestration. We spin up pods quickly, often pulling container images from various registries. But in this rush to innovate, a critical question remains: Do you really know what’s running in your cluster?

If your answer includes trust or assumptions about image integrity, your cluster may be operating on blind faith — a risky approach in an increasingly sophisticated supply chain attack era.

As organizations increasingly rely on containers to package and deploy their applications, ensuring the integrity and authenticity of the container images running in their clusters becomes paramount. Image verification isn’t just a “nice-to-have”; it’s a non-negotiable pillar of a robust Kubernetes security posture.

Why Should You Verify Container Images?

Container images are the building blocks of your Kubernetes applications. They encapsulate your code, its dependencies, and the runtime environment. However, this convenience also introduces potential vulnerabilities if the images are not properly vetted.

Here’s why image verification isn’t optional anymore:

• 🔓 Supply Chain Attacks: Attackers are increasingly targeting the software supply chain, injecting malicious code into legitimate-seeming images. Without verification, you’re a downstream victim waiting to happen.
• 🐞 Known Vulnerabilities: Many images rely on base layers that include outdated or vulnerable packages. Unverified images may expose you to CVEs (Common Vulnerabilities and Exposures) without your knowledge.
• 🔧 Misconfigurations: Images running as root, exposing unused ports, or containing hardcoded secrets create easy access points for attackers.
• 🎯 Human Error: Developers might accidentally use an older or similarly named but insecure image version. Without strict checks, mistakes slip into production.
• 📋 Compliance Failures: Standards like PCI DSS, SOC 2, and HIPAA mandate proof of software integrity and provenance. Running unverified images could mean failed audits and regulatory penalties.

Without strong verification systems, your Kubernetes cluster may become an unregulated environment of unchecked software, putting your organization at considerable risk.

How Kyverno Solves and Simplifies Image Verification

The Kubernetes ecosystem offers powerful tools to move beyond trust and enforce verifiable integrity. One such standout solution is Kyverno, a policy engine designed specifically for Kubernetes.

Kyverno acts as an admission controller, intercepting API requests and applying policies before workloads are admitted to the cluster. This makes it ideal for enforcing image verification policies at deployment time.

Key benefits of using Kyverno for image verification:

• ✅ Verify Image Signatures: Enforce cryptographic signing to ensure images are authentic and untampered.
• 📜 Check Attestations: Validate signed metadata about the image, such as scan status or build provenance.
• 🔒 Restrict Registries: Only allow images from trusted sources.
• 🏷️ Enforce Tagging Standards: Ensure images use explicit tags (e.g., not latest) and follow versioning conventions.

Examples of Kyverno Policies for Image Verification

Let’s explore a few real-world policy examples. Before using them, ensure Kyverno is installed in your cluster.

Scenario 1: Restrict Images to Approved Registries

A simpler but effective policy is to ensure images only come from your organization’s trusted registries.

---
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-image-registries
spec:
  validationFailureAction: Enforce # Block deployments if validation fails
  rules:
  - name: validate-registries
    match:
      any:
      - resources:
          kinds:
          - Pod
          - Deployment
          - StatefulSet
          - Job
          - CronJob
    validate:
      message: "Images must be pulled from approved registries (gcr.io or my.private.registry)."
      pattern:
        spec:
          containers:
          - image: "gcr.io/* | my.private.registry/*" # Allowed registry patterns

If an image from an unapproved registry is used, the deployment will be blocked with a clear validation message.

Scenario 2: Ensuring Images are Signed with Cosign

Cosign, a key component of the Sigstore project, is a widely adopted tool for cryptographically signing and verifying software artifacts and storing these signatures and attestations within an OCI registry. Ensure the public keys for the image verification are accessible, either in Kubernetes Secrets or via URL

Kyverno directly integrates with Cosign via its verifyImages rule to enforce policies that validate container image signatures and in-toto attestations. This ensures only trusted and verified images are deployed to the Kubernetes cluster.

Here’s a Kyverno ClusterPolicy that ensures all images deployed in the production namespace are signed by a specific public key:

---
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: check-image-signatures
spec:
  validationFailureAction: Enforce
  background: false
  webhookTimeoutSeconds: 30
  failurePolicy: Fail
  rules:
    - name: verify-image-signature
      match:
        any:
        - resources:
            kinds:
              - Pod
            namespaces:
              - production
      verifyImages:
      - imageReferences:
        - "registry.example.com/*:*" # Adjust to your image pattern
        attestors:
        - count: 1
          entries:
          - keys:
              publicKeys: | #The public key may either be defined in the policy directly or reference a standard Kubernetes Secret elsewhere in the cluster by specifying it in the format k8s://<namespace>/<secret_name>. The named Secret must specify a key cosign.pub containing the public key used for verification.
                -----BEGIN PUBLIC KEY-----
                MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEyourPublicKeyContentHere...
                -----END PUBLIC KEY-----

A signed image can be deployed as usual, and attempting to run an unsigned image will result in a policy error as follows:

Scenario 3: Verifying Vulnerability Scan Attestations

A key aspect of maintaining software supply chain integrity is performing regular vulnerability scans on images. Initial build-time scans are a starting point, but scans must be repeated as new vulnerabilities emerge. Kyverno helps enforce this by checking for attestations that prove an image has successfully undergone a recent vulnerability scan.

Here’s a Kyverno ClusterPolicy from Trivy enforces a validation check on Pod images to ensure their vulnerability scans are not over one week.

---
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: check-vulnerabilities
spec:
  validationFailureAction: enforce
  webhookTimeoutSeconds: 30
  failurePolicy: Fail
  rules:
    - name: not-older-than-one-week
      match:
        any:
        - resources:
            kinds:
              - Pod
      verifyImages:
      - imageReferences:
        - "registry.example.com/*:*" # Adjust to your image pattern
        attestations:
        - predicateType: cosign.sigstore.dev/attestation/vuln/v1
          conditions:
          - all:
            - key: "{{ time_since('','{{metadata.scanFinishedOn}}','') }}"
              operator: LessThanOrEquals
              value: "168h"

Kyverno will block pod creation if the image has not been scanned recently for vulnerabilities and is missing a Cosign-signed vulnerability scan attestation.

These are just a few examples. Kyverno’s flexibility allows for much more granular control, including checking for specific image tags and labels or even denying images with high-severity vulnerabilities based on attestation data.

Conclusion

Image verification is not just a best practice; it’s a fundamental necessity for secure cloud-native operations. Tools like Kyverno provide a powerful and flexible way to move from a position of blind trust to one of verifiable security. By implementing image signature verification, attestation checks, and registry restrictions, you can build a strong defense against a wide range of threats targeting the software supply chain.

Explore Kyverno documentation and Cosign to begin securing your container workloads today. If you’d like to know more or are interested in our services, don’t hesitate to get in touch. You can contact us here.