Image Signing and Admission Control

Image Signing: Proving Provenance

Container images are the unit of deployment in Kubernetes. When a pod starts, the kubelet pulls the image and runs it — with no verification that the image was built by your pipeline and hasn't been tampered with. Image signing closes this gap by cryptographically proving which pipeline produced an artifact.

The supply chain problem

A container image passes through many hands before it runs in production:

1. A developer writes code and creates a pull request
2. A CI system builds the image from the source
3. The image is pushed to a registry
4. Kubernetes pulls the image and runs it

At any point, an attacker can:

• Inject malicious code into the build
• Replace the image in the registry with a trojaned version
• Compromise the CI system and build from modified source
• Pull an image from a public registry that happens to have the same name

Without image signing, there is no way to verify that the image running in production is the image your pipeline built.

How image signing works

Image signing uses public-key cryptography:

1. The build pipeline has a private key (kept secret)
2. After building the image, the pipeline creates a signature using the private key
3. The signature is stored alongside the image in the registry
4. At deployment time, the cluster verifies the signature using the public key

# Sign an image with Cosign (Sigstore)
cosign sign --key cosign.key registry.company.com/myapp:v1.2.3

# Verify a signature
cosign verify --key cosign.pub registry.company.com/myapp:v1.2.3

# Output:
# Verification for registry.company.com/myapp:v1.2.3 --
# The following checks were performed on each of these signatures:
#   - The cosign claims were validated
#   - Existence of the claims in the transparency log was verified offline
#   - The signatures were verified against the specified public key

If the image is modified after signing, the signature verification fails — the cryptographic proof no longer matches the image content.

Sigstore and keyless signing

Sigstore is a project that simplifies image signing by eliminating the need to manage signing keys:

# Keyless signing — uses OIDC identity, no key management
cosign sign registry.company.com/myapp:v1.2.3

# The signature is tied to the OIDC identity (e.g., GitHub Actions workflow)
# Verification checks that the signature was created by the expected identity
cosign verify \
  --certificate-identity=https://github.com/company/repo/.github/workflows/build.yml@refs/heads/main \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com \
  registry.company.com/myapp:v1.2.3

Keyless signing uses short-lived certificates tied to an OIDC identity (like a GitHub Actions workflow). The signature proves that the image was built by a specific workflow run — no long-lived keys to manage or leak.

Signing in CI/CD

Signing should happen automatically in the build pipeline:

# GitHub Actions example
- name: Build and push
  run: |
    docker build -t registry.company.com/myapp:${{ github.sha }} .
    docker push registry.company.com/myapp:${{ github.sha }}

- name: Sign image
  uses: sigstore/cosign-installer@v3
- run: |
    cosign sign --yes \
      registry.company.com/myapp:${{ github.sha }}

The signature is created immediately after the push, ensuring every image in the registry is signed.

Admission Controllers: Enforcing Policy at Deploy Time

Signing an image proves its provenance, but something needs to verify that signature before the image runs. That's the job of admission controllers — Kubernetes interceptors that inspect (and can reject) resources before they're created.

How admission control works

When you submit a resource to the API server (e.g., kubectl apply), it goes through an admission chain:

kubectl apply → API Server → MutatingAdmissionWebhooks → ValidatingAdmissionWebhooks → etcd

• Mutating webhooks can modify the resource (e.g., inject sidecar containers)
• Validating webhooks can accept or reject the resource (e.g., reject pods that don't meet policy)

OPA Gatekeeper

OPA Gatekeeper is an admission controller that evaluates resources against policies written in Rego:

# Policy: reject pods that run as root
package k8spspuser

violation[msg] {
    input.review.object.spec.containers[_].securityContext.runAsNonRoot == false
    msg := "Container must not run as root"
}

violation[msg] {
    not input.review.object.spec.containers[_].securityContext.runAsNonRoot
    msg := "Container must set runAsNonRoot: true"
}

# Gatekeeper ConstraintTemplate
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8spspuser
spec:
  crd:
    spec:
      names:
        kind: K8sPSPUser
  targets:
  - target: admission.k8s.gatekeeper.sh
    rego: |
      package k8spspuser
      violation[msg] {
          input.review.object.spec.containers[_].securityContext.runAsNonRoot == false
          msg := "Container must not run as root"
      }

Kyverno

Kyverno is a policy engine designed specifically for Kubernetes. Policies are written as Kubernetes resources (no Rego required):

# Kyverno policy: require non-root containers
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-non-root
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-run-as-non-root
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "Containers must run as non-root"
      pattern:
        spec:
          containers:
          - securityContext:
              runAsNonRoot: true
---
# Kyverno policy: reject privileged pods
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privileged
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-privileged
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "Privileged containers are not allowed"
      pattern:
        spec:
          containers:
          - securityContext:
              =(privileged): "false"

Common admission policies

A baseline policy set should enforce:

1. Non-root containers: runAsNonRoot: true
2. No privileged pods: privileged: false
3. No host networking: hostNetwork: false
4. No host PID/IPC: hostPID: false, hostIPC: false
5. Read-only root filesystem: readOnlyRootFilesystem: true
6. Dropped capabilities: capabilities.drop: [ALL]
7. Approved registries: only images from registry.company.com
8. Signed images: only images with valid signatures

# Kyverno: restrict to approved registries
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-registries
spec:
  validationFailureAction: Enforce
  rules:
  - name: validate-registry
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "Only images from registry.company.com are allowed"
      pattern:
        spec:
          containers:
          - image: "registry.company.com/*"

Verifying signatures in admission

With Cosign and Kyverno, you can verify image signatures at admission time:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signatures
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-signature
    match:
      resources:
        kinds:
        - Pod
    verifyImages:
    - imageReferences:
      - "registry.company.com/*"
      attestors:
      - entries:
        - keys:
            publicKeys: |
              -----BEGIN PUBLIC KEY-----
              MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE...
              -----END PUBLIC KEY-----

This policy rejects any pod that uses an image from registry.company.com without a valid signature from the expected public key.