||Protect source code
Maintain standard base images and ensure that all workloads use them
- Dockerfile provenance (ensure hasn't been tampered with)
- Harden Dockerfile (see Harden Base Images)
Define a Build process for Images
- 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)
- 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
||Use private registries, and restrict public registry usage
Image Integrity: Implement image signing (Notary/TUF/in-toto)
- Examples: Artifactory, Harbor
- Where deployed
- Who can pull images
- Who can push images
- Certified images only VS developers can use any image
- Authentication (SSO) / Authorization (RBAC)
- Vulnerability scanning
- Image signing
- Pipeline managed
- Highly available
- Globally available
- Download images from trusted sources, like a trusted Docker registry
- Enable docker trust enforcement (
- Enforce mandatory signature verification for any image that is going to be pulled or run
- Scan all images for security vulnerabilities continuously
- Decide which types/severity of issues should prevent deployments
- 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?
Malicious deployment definitions (yaml)
- Referring to an image by its
digest, rather than by
tag, help ensure that the image is the intended one
- Secure source code
- Don't pull from the Internet
- 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?
||Monitoring and Auditing
- Mandate the use of specific logging solutions, to ensure that information about system activity persists across container instantiations
- Example: Sysdig Falco
- 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