Skip to content

Container Pipelines

Image Pipeline

Phase Description
Build Time Protect source code
  • Dockerfile provenance (ensure hasn't been tampered with)
  • Harden Dockerfile (see Secure Dockerfiles)
Maintain standard base images and ensure that all workloads use them
  • Finalize list of images (version and sub version) deemed acceptable and that are going to be provided to the application teams
  • Use minimal, container-centric host systems (CoreOS, Distroless, Alpine)
Define a Build process for Images
  • Update and rebuild images periodically to grab the newest security patches
  • Integrate a vulnerability scanner (Clair, Trivy) as a mandatory step of the CI/CD
  • Attacks on the Build machine → secure CI/CD server
Image Storage Use private registries, and restrict public registry usage
  • Examples: Artifactory, Harbor
  • Considerations:
    • Where deployed
    • Who can pull images
    • Who can push images
    • Certified images only VS developers can use any image
  • Requirements:
    • Authentication (SSO) / Authorization (RBAC)
    • Vulnerability scanning
    • Image signing
    • Pipeline managed
    • Highly available
    • Globally available
Image Integrity: Implement image signing (Notary/TUF/in-toto)
  • Download images from trusted sources, like a trusted Docker registry
  • Enable docker trust enforcement (export DOCKER_CONTENT_TRUST=1)
  • Enforce mandatory signature verification for any image that is going to be pulled or run
Image Scanning
  • Approach
    • Scan all images for security vulnerabilities continuously
    • Decide which types/severity of issues should prevent deployments
  • Goals
    • Prevent malicious actors inserting objects into your builds
    • Enforce company-wide standards on software usage
    • Quickly patch known and standard CVEs
  • When images are uploaded to your registry, you have a golden opportunity to check that they conform to standards
  • Questions that could be answered:
    • Is there a shellshock version of bash on there?
    • Is there an out of date SSL library?
    • Is it based on a fundamentally insecure or unacceptable base image?
    • Are there "wrong" or out of date (based on your org's standards) development libraries, or tools being used?
Image Deployment Tag resources
  • Referring to an image by its digest, rather than by tag, help ensure that the image is the intended one
Malicious deployment definitions (yaml)
  • Secure source code
  • Don't pull from the Internet
Admission Controllers
  • Admission controllers can perform several vital security checks on the container image before it is instantiated into a running container:
    • Has the image been scanned for vulnerabilities?
    • Does the image come from a trusted registry?
    • Is the image signed?
    • Is the image approved?
    • Does the image run as root?
Operate Monitoring and Auditing
  • Mandate the use of specific logging solutions, to ensure that information about system activity persists across container instantiations
  • Example: Sysdig Falco
  • Requirements
    • Can you tell who ran a container?
    • Can you tell who built a container?
    • Can you determine what a container did once it's gone?
    • Can you determine what a container might have done once it's gone?
  • Grafeas makes it possible to ensure that a container:
    • Has been built by us and comes from our (or a trusted) container repository
    • Has passed CI tests
    • Does not run as root
    • Does not introduce any new vulnerabilities (scanned)
    • Is deployed with the appropriate security context

Binary Authorization


Software Delivery Shield
General Supply Chain
CI/CD Pipeline


Link Description
Implementing Quarantine Pattern for Container Images Some ways to implement a quarantine pattern for container images or other artifacts stored in OCI registries

  1. How to secure Kubernetes deployment with signature verification: How to set up a solution ensuring nothing runs in your cluster without a signature verification by a known authority and verified by an admission controller