KCSA — Artifact Repository & Registry Security

7 minute read

What Is an Artifact Repository?

An artifact repository (or container registry) is where your container images are stored and distributed from. When Kubernetes pulls an image to run a Pod, it pulls from a registry.

If the registry is compromised — or if you’re pulling from an unverified source — you could be running malicious code in your cluster without knowing it.

Registry security is the last checkpoint before an image becomes a running workload. It’s your final opportunity to verify that what you’re deploying is trustworthy.

Container Registries Overview

Registry Type Provider Key Features
Docker Hub Public + Private Docker Largest public registry; rate-limited for free tier; official images
Amazon ECR Private (public available) AWS Integrated with EKS and IAM; automatic scanning; lifecycle policies
Google Artifact Registry Private GCP Replaces GCR; integrated with GKE; vulnerability scanning
Azure Container Registry (ACR) Private Azure Integrated with AKS; geo-replication; content trust
GitHub Container Registry (GHCR) Public + Private GitHub Integrated with GitHub Actions; free for public images
Harbor Private (self-hosted) CNCF Open-source enterprise registry; scanning, replication, access control, content trust
Quay Private (hosted + self-hosted) Red Hat Clair integration for scanning; RBAC; automated builds

How to Choose

  • Public images (open-source tools, base images): Docker Hub, GHCR
  • Cloud-native workloads: Use your cloud provider’s registry (ECR, GAR, ACR) for best integration
  • Enterprise / on-premises: Harbor or Quay for full control
  • Multi-cloud: Harbor for portability and vendor neutrality

Public vs Private Registries

This is a key topic for the KCSA exam. Pulling images from public registries introduces risks that private registries can mitigate.

Risk Comparison

Factor Public Registry (e.g., Docker Hub) Private Registry (e.g., ECR, Harbor)
Image trust ⚠️ Anyone can publish; risk of typosquatting ✅ Only authorized users can push
Availability ⚠️ Subject to rate limits and outages ✅ Under your control; no rate limits
Vulnerability scanning ⚠️ Optional; not enforced ✅ Can enforce scanning before pull
Access control ⚠️ Public by default ✅ Fine-grained RBAC
Audit trail ⚠️ Limited ✅ Full access logs
Content integrity ⚠️ Tags are mutable; images can be overwritten ✅ Can enforce immutable tags and signing
Supply chain risk ⚠️ Higher — unknown provenance ✅ Lower — controlled pipeline pushes images
Network exposure ⚠️ Images pulled over the internet ✅ Can use VPC endpoints for private access

Never pull directly from public registries in production. Instead, mirror trusted images into your private registry, scan them, and pull from there.

Best Practice: Mirror and Scan

Public Registry → Pull to staging → Scan with Trivy → If clean, push to private registry → Prod pulls from private

This gives you:

  • Control over what enters your environment
  • A scanning gate before images reach production
  • No dependency on public registry availability during deployments

Registry Security Best Practices

Practice Description
Use private registries All production images should come from your own registry
Enable vulnerability scanning Scan on push and periodically re-scan for new CVEs
Enforce image signing Require valid signatures before images can be pulled/deployed
Implement RBAC Separate push (CI/CD only) from pull (cluster nodes) permissions
Enable immutable tags Prevent overwriting existing image tags
Use image digests Reference images by sha256 digest in deployments
Set retention policies Automatically delete old, untagged, or vulnerable images
Enable audit logging Track who pushed, pulled, or deleted images and when
Use TLS All communication with the registry should be encrypted (HTTPS)
Restrict network access Use VPC endpoints or firewall rules to limit who can reach the registry

Image Pull Policies in Kubernetes

Kubernetes uses imagePullPolicy to determine when to pull images from the registry. This has security implications.

Pull Policies

Policy Behavior Security Impact
Always Pulls the image every time a Pod starts ✅ Always gets the latest version (good for security if images are scanned)
IfNotPresent Pulls only if the image isn’t already on the node ⚠️ Could use a cached image that’s now known to be vulnerable
Never Never pulls — image must already be on the node ⚠️ Only for special cases; images must be pre-loaded

Default Behavior

  • If you use the latest tag, Kubernetes defaults to Always
  • If you use a specific tag (e.g., nginx:1.25), Kubernetes defaults to IfNotPresent
  • If you use a digest, Kubernetes defaults to IfNotPresent

For the exam, know that Always ensures you get the freshest image but adds latency, while IfNotPresent is more efficient but could serve a stale (vulnerable) cached image. Using digests with IfNotPresent is the recommended approach — the digest guarantees the content, and caching avoids unnecessary pulls.

Example: Using Digest with Pull Policy

apiVersion: apps/v1
kind: Deployment
metadata:
  name: secure-app
spec:
  template:
    spec:
      containers:
      - name: app
        image: myregistry.io/myapp@sha256:a8281ce42034...
        imagePullPolicy: IfNotPresent

Image Policy Enforcement

Even if you follow best practices, how do you enforce them at the cluster level? You use admission controllers that intercept image pull requests and block those that don’t meet your policies.

Policy Enforcement Tools

Tool Type How It Works
OPA Gatekeeper Admission controller (CNCF) Uses Rego policies to validate resources; can block images from untrusted registries
Kyverno Admission controller (CNCF) Kubernetes-native policy engine; uses YAML policies (no new language to learn)
Sigstore Policy Controller Admission controller Verifies cosign signatures and attestations before allowing image deployment
Portieris Admission controller (IBM) Enforces Docker Content Trust / Notary signatures

Example Policies

Block images from untrusted registries (Kyverno):

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-image-registries
spec:
  validationFailureAction: Enforce
  rules:
  - name: validate-registries
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "Images must come from myregistry.io"
      pattern:
        spec:
          containers:
          - image: "myregistry.io/*"

Require image signatures (Kyverno with cosign):

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signatures
spec:
  validationFailureAction: Enforce
  rules:
  - name: verify-signature
    match:
      any:
      - resources:
          kinds:
          - Pod
    verifyImages:
    - imageReferences:
      - "myregistry.io/*"
      attestors:
      - entries:
        - keyless:
            subject: "ci@mycompany.com"
            issuer: "https://accounts.google.com"

For the KCSA exam, know that OPA Gatekeeper and Kyverno are the two primary admission-controller-based policy engines. Kyverno is often considered more approachable because its policies are written in YAML, while Gatekeeper uses the Rego language.

Docker Content Trust / Notary

Docker Content Trust (DCT) is the original image signing mechanism built into Docker. It’s based on The Update Framework (TUF) and implemented by the Notary project.

How Docker Content Trust Works

  1. When enabled (DOCKER_CONTENT_TRUST=1), Docker clients will only pull and run signed images
  2. Image publishers sign their images using a private key
  3. The signature is stored in a Notary server
  4. Pulling clients verify the signature before using the image

DCT vs cosign

Feature Docker Content Trust (Notary) cosign (Sigstore)
Key management Requires managing private keys Supports keyless signing (OIDC)
Transparency No public transparency log Signatures recorded in Rekor transparency log
Ease of use Complex key management Simpler — especially in keyless mode
Adoption trend Legacy; still used but declining Growing rapidly; becoming the standard
Stored in Separate Notary server OCI registry (alongside the image)

While DCT/Notary is still relevant (especially in enterprise environments), cosign/Sigstore is the direction the ecosystem is moving. The KCSA exam may reference both.

Harbor as an Enterprise Registry

Harbor is a CNCF graduated project and the most widely used open-source enterprise container registry.

Harbor Features

Feature Description
Vulnerability Scanning Built-in integration with Trivy (or Clair); scans on push; blocks pulls of vulnerable images
Content Trust Supports Notary for image signing and verification
Replication Replicate images between Harbor instances or to/from other registries (ECR, DockerHub, etc.)
RBAC Project-level access control — separate teams get separate registries with distinct permissions
Audit Logging Full audit trail of pushes, pulls, deletes, and configuration changes
Image Retention Policies to automatically clean up old or untagged images
Proxy Cache Act as a pull-through cache for Docker Hub and other registries — reduces external pulls and rate limit risk
Robot Accounts Service accounts for CI/CD pipelines with limited, scoped permissions
Immutable Tags Prevent overwriting existing tags
Quotas Limit storage usage per project

Why Harbor for KCSA?

Harbor is often referenced in KCSA context because it’s:

  • Open-source and CNCF graduated (production-ready)
  • Provides a comprehensive set of security features in one tool
  • Commonly used in enterprise and regulated environments
  • A practical answer to “how do you implement registry security?”

Key Takeaways for the Exam

  1. Always use private registries for production — never pull directly from public registries
  2. Mirror and scan public images before allowing them into your environment
  3. Image pull policies: Always ensures freshest image; IfNotPresent uses cache; use digests for immutable references
  4. OPA Gatekeeper and Kyverno are the two main admission controllers for enforcing image policies
  5. Kyverno uses YAML policies; OPA Gatekeeper uses Rego — both can restrict image sources
  6. Docker Content Trust (Notary) is the legacy signing mechanism; cosign (Sigstore) is the modern standard
  7. Harbor is the CNCF graduated enterprise registry — know its key features (scanning, RBAC, replication, content trust)
  8. Immutable tags prevent image tag overwriting — a critical registry security feature
  9. Enforce the principle: build → scan → sign → push → verify → deploy
  10. Registry security is the last checkpoint before an image becomes a running workload — make it count

Next up: Cloud Native Security — Practice Questions — test your knowledge across all five topics in this chapter.

Updated:

You may also enjoy