Skip to content

Overview

Image Pipeline

Phase Description
Build Time Protect source code
  • Dockerfile provenance (ensure hasn't been tampered with)
  • Harden Dockerfile (see Harden Base Images)
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?
Governance
  • 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

Other Resources

Link Notes
Dependencies, Confusions, and Solutions: What Did Twilio Do to Solve Dependency Confusion
  • Naming conventions for all internal packages
  • Block proxying of certain packages
  • Internal package manager as single source
  • Restrict deployed hosts from accessing the registry
  • Controls for laptop access
Back to top