Supply Chain and Container Image Security on Kubernetes

TL;DR: Kubernetes image security starts well before deployment. Scan your images at every stage of the CI/CD pipeline, sign them with Cosign, use minimal base images (Alpine < 5 MB), and enforce admission controllers to block non-compliant images. A compromised container supply chain can expose your entire infrastructure.

To master these security practices in production, discover the LFS460 Kubernetes Security Fundamentals training.

Why Kubernetes Image Security Is Critical in 2026

Kubernetes image security represents the primary attack vector on cloud-native infrastructures today. According to the CNCF Annual Survey 2025, 82% of container users run Kubernetes in production. This massive adoption makes the container supply chain a prime target for attackers.

Key takeaway: A compromised image deployed in your cluster can create a persistent backdoor, exfiltrate data, or serve as an entry point for lateral movement.

Software supply chain attacks increased by 742% between 2019 and 2024. The SolarWinds incident, npm compromises, and attacks targeting public Docker registries demonstrate that security can no longer be limited to runtime.

Chris Aniszczyk, CTO of the CNCF, states: "Kubernetes is no longer experimental but foundational. Soon, it will be essential to AI as well." (CNCF State of Cloud Native 2026). This central position requires a proactive approach to Kubernetes security.

The 5 Pillars of Kubernetes Image Security

1. Minimal Base Images

Reduce the attack surface by choosing lightweight base images. According to Medium Docker Optimization, the differences are significant:

# Avoid
FROM ubuntu:22.04

# Prefer
FROM gcr.io/distroless/static-debian12:nonroot

The goal is to keep your microservice images under 200 MB (DevOpsCube Docker Guide). This practice integrates with Docker containerization best practices.

2. Systematic Vulnerability Scanning

Integrate scanning at every stage of your CI/CD pipeline:

# GitHub Actions - Scan with Trivy
- name: Scan image
uses: aquasecurity/trivy-action@master
with:
image-ref: '${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }}'
format: 'sarif'
severity: 'CRITICAL,HIGH'
exit-code: '1'

Reference tools in 2026:

• Trivy: Open source, fast, native CI/CD integration
• Grype: Anchore, comprehensive CVE database
• Snyk Container: Developer context, automatic fixes
• Clair: CoreOS/Red Hat, static scanner

Key takeaway: Scan at three moments: during local build, before pushing to registry, and regularly in production to detect new CVEs.

3. Image Signing and Verification

Sign every image to guarantee its integrity and origin. Cosign (Sigstore project) has become the standard:

# Generate a key pair
cosign generate-key-pair

# Sign an image
cosign sign --key cosign.key registry.example.com/app:v1.2.3

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

Integration with Kubernetes admission controllers allows you to automatically block unsigned images:

apiVersion: policy.sigstore.dev/v1alpha1
kind: ClusterImagePolicy
metadata:
name: require-signature
spec:
images:
- glob: "registry.example.com/**"
authorities:
- keyless:
url: https://fulcio.sigstore.dev
identities:
- issuer: https://accounts.google.com
subject: team@example.com

4. SBOM (Software Bill of Materials)

Generate an SBOM for each image to track dependencies and react quickly to new vulnerabilities:

# Generate an SBOM with Syft
syft registry.example.com/app:v1.2.3 -o spdx-json > sbom.json

# Attach the SBOM to the image with Cosign
cosign attach sbom --sbom sbom.json registry.example.com/app:v1.2.3

SBOM is becoming mandatory in many regulatory contexts (US Executive Order, NIS2 in Europe). It enables responding in hours rather than days to incidents like Log4Shell.

5. Private Registries and Access Control

Centralize your images in a private registry with:

• OIDC/SSO authentication
• Granular RBAC per namespace/project
• Automatic retention policy
• Geographic replication
• Integrated scanning

# ImagePullSecrets in Kubernetes
apiVersion: v1
kind: Secret
metadata:
name: registry-credentials
type: kubernetes.io/dockerconfigjson
data:
.dockerconfigjson: <base64-encoded-config>
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: app-sa
imagePullSecrets:
- name: registry-credentials

Kubernetes Image Security: The Secure CI/CD Pipeline

A robust pipeline for the container supply chain integrates security at every stage:

+-------------+    +-------------+    +-------------+    +-------------+
|   Commit    |--->|    Build    |--->|    Test     |--->|   Deploy    |
|  (pre-hook) |    | (scan deps) |    | (scan img)  |    |  (verify)   |
+-------------+    +-------------+    +-------------+    +-------------+
|                  |                  |                  |
v                  v                  v                  v
Secrets           Trivy/Grype        Sign with         Admission
scanning          SBOM generation    Cosign            Controller

Step 1: Dependency Analysis at Build

# GitLab CI example
build:
stage: build
script:
- docker build -t $IMAGE_TAG .
- trivy fs --severity HIGH,CRITICAL --exit-code 1 .
- syft $IMAGE_TAG -o cyclonedx-json > sbom.json

Step 2: Post-Build Scan and Signing

sign:
stage: sign
script:
- trivy image --exit-code 1 --severity CRITICAL $IMAGE_TAG
- cosign sign --key $COSIGN_KEY $IMAGE_TAG
- cosign attach sbom --sbom sbom.json $IMAGE_TAG

Step 3: Verification at Deployment

Use Kyverno or OPA Gatekeeper to enforce policies:

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

This approach aligns with Kubernetes production deployment principles and monitoring and troubleshooting strategies.

Admission Controllers for Image Security

Admission controllers are your last line of defense.

Essential Policies to Implement

# Pod Security Standards - Restricted
apiVersion: v1
kind: Namespace
metadata:
name: production
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/warn: restricted

Key takeaway: Combine Pod Security Standards (native Kubernetes) with Kyverno or Gatekeeper for custom image policies.

Securing the Container Supply Chain at Runtime

Security does not stop at deployment. Runtime monitoring detects abnormal behaviors:

Falco for Intrusion Detection

# Custom Falco rule
- rule: Unexpected process in container
desc: Detect shell spawned in container
condition: >
spawned_process and container and
shell_procs and proc.pname != "entrypoint.sh"
output: >
Shell spawned in container (user=%user.name container=%container.name
image=%container.image.repository command=%proc.cmdline)
priority: WARNING

Sysdig Secure and Tetragon

For critical environments, these tools offer:

• eBPF-based behavioral analysis
• Real-time blocking
• Post-incident forensics
• SIEM integration

These practices complement ConfigMaps and Secrets configuration and Kubernetes RBAC.

Kubernetes Image Security Checklist

Before build:

• [ ] Use a minimal base image (distroless, Alpine)
• [ ] Scan application dependencies
• [ ] Configure secrets via CI environment variables (never hardcoded)

At build:

• [ ] Multi-stage build to reduce size
• [ ] Non-root user in Dockerfile
• [ ] OCI labels for traceability

FROM golang:1.22 AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o /app/bin

FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=builder /app/bin /app
USER nonroot:nonroot
ENTRYPOINT ["/app"]

After build:

• [ ] Vulnerability scan (Trivy/Grype)
• [ ] SBOM generation
• [ ] Sign with Cosign
• [ ] Push to private registry

At deployment:

• [ ] Admission controller verifies signature
• [ ] Pod Security Standards applied
• [ ] ImagePullPolicy: Always
• [ ] No :latest in production

In production:

• [ ] Runtime monitoring (Falco)
• [ ] Periodic re-scan of deployed images
• [ ] Alerts on new critical CVEs

This checklist applies to Kubernetes CI/CD pipeline workflows and GitOps strategies.

Training and Certification to Master Image Security

The complexity of the container supply chain requires structured training. According to 70% of organizations use Kubernetes in cloud environments, most with Helm. This massive adoption creates an urgent need for certified professionals.

The CKS (Certified Kubernetes Security Specialist) certification validates skills in:

• Supply chain security and image scanning
• Runtime security and detection
• Cluster hardening and network policies
• Attack surface minimization

Key takeaway: CKS requires CKA as a prerequisite. Prepare with the LFS460 4-day training.

For developers, the CKAD preparation includes containerization best practices. Administrators will start with CKA preparation.

Image Security Tools and Resources

The complete Kubernetes Training guide details learning paths suited to each profile.

Take Action: Secure Your Supply Chain

Kubernetes image security is no longer optional. With 71% of Fortune 100 companies using Kubernetes in production (CNCF Project Journey Report), attackers actively target these infrastructures.

Your next steps:

1. Audit your current pipeline with the checklist above
2. Implement automated scanning in CI/CD
3. Deploy admission controllers to block non-compliant images
4. Train your teams in cloud-native security practices

Recommended SFEIR Institute Training

• LFS460 Kubernetes Security Fundamentals: 4 days to master cluster and image security, and prepare for CKS certification
• LFS458 Kubernetes Administration: The foundations to understand architecture before securing
• LFD459 Kubernetes for Application Developers: Containerization best practices for developers

Contact our advisors to build a training path tailored to your team and explore OPCO funding options.