| 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?
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
|
