Q9: How do OCI Image Manifests, Multi-Architecture builds (Buildx), and Image Signing (Cosign) work? - DevOps & Kubernetes (50 Qs)

Deep Dive: OCI & Multi-Arch Image Supply Chain

An image tag (e.g., nginx:latest) in an OCI-compliant registry is not a single file—it is an OCI Image Index (Manifest List) pointing to separate image manifests for each CPU architecture (linux/amd64, linux/arm64, windows/amd64).

scss

                         [ Image Tag: api:v1.0.0 ]
                                     |
                                     v
                       +---------------------------+
                       | OCI Image Index (Manifest)|
                       +---------------------------+
                               /           \
                              /             \
      [ linux/amd64 Manifest ]               [ linux/arm64 Manifest ]
      - Layer 1 (amd64 SHA)                  - Layer 1 (arm64 SHA)
      - Layer 2 (amd64 SHA)                  - Layer 2 (arm64 SHA)

1. Building Multi-Arch Images with Docker Buildx

bash

# Create buildx instance with QEMU emulation
docker buildx create --name multi-builder --use
docker buildx inspect --bootstrap

# Build and push multi-architecture image directly to registry
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t registry.example.com/org/api:v1.2.0 \
  --push .

2. Cryptographic Image Signing with Cosign (Sigstore)

To guarantee image provenance and prevent supply chain attacks (man-in-the-middle tampering), CI/CD pipelines cryptographically sign images before pushing:

bash

# Generate keypair
cosign generate-key-pair

# Sign the remote OCI container image
cosign sign --key cosign.key registry.example.com/org/api:v1.2.0

# Verify signature in Kubernetes admission controller or CI
cosign verify --key cosign.pub registry.example.com/org/api:v1.2.0

Kubernetes admission controllers (such as Kyverno or OPA Gatekeeper) enforce that any container pod attempting to start without a verified signature is automatically blocked from running.