Secure Containers Policy
1. Objective
This policy defines the security requirements for the full lifecycle of containers: from the choice of base image, through building, scanning and signing, to runtime configuration and monitoring in production.
Containers offer logical isolation - not security isolation by default. A container without execution restrictions (running as root, with excessive capabilities, without a read-only filesystem, without a NetworkPolicy) has a potential impact on the host node and on other workloads that undermines the isolation advantages the technology could offer. Security in containers is not automatic - it is the result of deliberate configuration and systematic verification.
The objective of this policy is to ensure that:
- Images are built from trusted, minimal bases with the version pinned by digest
- Vulnerabilities in images are detected and blocked before production
- Images in production are signed and their integrity is verified before deploy
- Runtime configurations follow the principle of least privilege and are enforced by policy
- Secrets are never embedded in images
2. Scope
This policy applies to all containers used in development, integration, staging and production environments, including application containers, sidecar containers and infrastructure containers (e.g. proxies, service mesh).
3. Image building
3.1 Base image
| Requirement | L1 | L2 | L3 |
|---|---|---|---|
| Base image from a verified origin (official repository or internal catalogue) | Mandatory | Mandatory | Mandatory |
| Version pinned by SHA256 digest (not by floating tag) | Recommended | Mandatory | Mandatory |
| Minimal base image (distroless, alpine, slim) | Recommended | Mandatory | Mandatory |
| No unnecessary debug tools in the final image (curl, bash, wget) | Recommended | Mandatory | Mandatory |
3.2 Secure Dockerfile
The Dockerfile must follow these mandatory practices:
- Multi-stage build where applicable: separation between build environment and runtime image
-
USERset to a non-root user in the final instruction beforeCMD/ENTRYPOINT - No
ADDwith remote URLs (useCOPYfrom the local context) - No
--privilegedor--cap-addin build instructions - No secrets in
ARG,ENVorRUN(including exported variables) - Dockerfile linter (
hadolintor equivalent) with no blocking findings
3.3 Image registries
At L2/L3, images must be produced and stored in controlled internal registries:
- Internal registry as the source of images in production (no direct pulls from Docker Hub)
- Allowlist of authorised external registries (for base images)
- Access to the registry controlled by authentication - no anonymous access
4. Image scanning
The pipeline must include vulnerability scanning of the image produced:
| Gate | L1 | L2 | L3 |
|---|---|---|---|
| Image scanner (Trivy, Grype, Clair) | Alert | Blocks High/Critical | Blocks Medium+ |
| SBOM generated per image | Recommended | Mandatory | Mandatory |
| Scan of Dockerfile configurations (hadolint) | Recommended | Mandatory | Mandatory |
| Scan for secrets embedded in layers | Mandatory | Mandatory | Mandatory |
The scanning report must be archived as a pipeline artefact, associated with the image digest.
5. Signing and provenance
| Requirement | L1 | L2 | L3 |
|---|---|---|---|
| Image signed after build (Cosign or equivalent) | Optional | Recommended | Mandatory |
| Signature verified before deploy | Optional | Recommended | Mandatory |
| Provenance attestation (SLSA-like) | Not applicable | Recommended | Mandatory |
| Deploy blocked if the signature is missing or invalid | Not applicable | Recommended | Mandatory |
At L3, only images signed by the organisation's pipeline must be admitted to production. Unsigned images or images with a signature of unknown origin must be rejected by the admission controller.
6. Runtime configuration (hardening)
6.1 Mandatory securityContext
All running containers must have the following securityContext configured (Kubernetes) or equivalent:
| Configuration | L1 | L2 | L3 |
|---|---|---|---|
runAsNonRoot: true | Mandatory | Mandatory | Mandatory |
allowPrivilegeEscalation: false | Mandatory | Mandatory | Mandatory |
readOnlyRootFilesystem: true | Recommended | Mandatory | Mandatory |
capabilities: drop: ["ALL"] | Recommended | Mandatory | Mandatory |
privileged: false | Mandatory | Mandatory | Mandatory |
seccompProfile: RuntimeDefault (or more restrictive) | Recommended | Mandatory | Mandatory |
6.2 Volumes and mounts
- No mounting of
/var/run/docker.sock(container access to the Docker socket) - Volumes mounted in read-only mode whenever possible
- No sharing of host namespaces (
hostNetwork,hostPID,hostIPC) without formal justification
6.3 Admission policies (Kubernetes)
At L2/L3 with Kubernetes, admission policies must be enforced by an admission controller (OPA/Gatekeeper, Kyverno, or PSA):
- Policies that enforce a minimum
securityContextin all production namespaces - Violations blocked and audited with timestamp, actor and pod details
- Policies versioned and approved by the AppSec Engineer
7. Network isolation
- NetworkPolicy defined for each namespace/workload (deny-all by default, explicit permit)
- No unrestricted communication between namespaces or between pods without an explicit policy
- Egress controlled to the necessary external services (allowlist of destinations)
8. Secrets management in containers
Secrets must not be included in container images under any circumstances:
- No secrets in
ENVvariables in the Dockerfile - No secrets in build
ARG(they persist in the image layers) - Secrets injected at runtime via Kubernetes Secrets (with encryption at rest) or an external vault (Vault, AWS Secrets Manager, etc.)
- Preferred alternative at L3: workload identity (IRSA, GKE Workload Identity, Vault Agent) - no persisted secrets
9. Runtime monitoring
| Requirement | L1 | L2 | L3 |
|---|---|---|---|
| Logging of runtime events (start, stop, errors) | Basic | Mandatory | Mandatory |
| Runtime anomaly detection (Falco, eBPF-based) | Not applicable | Recommended | Mandatory |
| Alerts in the event of a runtime policy violation | Not applicable | Mandatory | Mandatory |
| Automatic response to critical anomalies (kill container) | Not applicable | Recommended | Recommended |
10. Expected artefacts
| Artefact | Description | Retention |
|---|---|---|
| Image scan report (Trivy/Grype) | Vulnerabilities per build | 90 days (L2), 1 year (L3) |
| Image SBOM | Inventory per build | See SBOM Policy |
| Image signature | Per build, in the image registry | While the image is in use |
| Provenance attestation | Per build | 1 year (L2), 2 years (L3) |
| Admission logs | Policy violations in the cluster | 1 year (L2), 2 years (L3) |
11. Responsibilities
| Role | Responsibility |
|---|---|
| Developer | Write secure Dockerfiles; do not include secrets; use approved base images |
| DevOps / SRE | Configure the build and scanning pipeline; manage the image registry; configure runtime policies |
| AppSec Engineer | Define scanning thresholds; approve admission policies; review securityContext configurations |
| GRC / Compliance | Audit scanning reports; verify the compliance of runtime policies; validate retention |
12. Review and audit of this policy
This policy must be reviewed annually or after any of the following events:
- Incident originating in an image vulnerability or a runtime misconfiguration
- Change of the container orchestrator or of the admission controller
- Publication of a new version of the CIS Docker or Kubernetes benchmarks
13. Normative and technical references
| Reference | Relevance |
|---|---|
| SbD-ToE Ch. 09 - Containers and Images | Building, scanning, runtime, SBOM, signing |
Golden Base Images Policy (24_policy-golden-base-images.md) | Catalogue of approved base images |
SBOM Policy (11_policy-sbom.md) | SBOM per image |
Secrets Management Policy (18_policy-gestao-segredos.md) | Secrets in containers |
| CIS Docker Benchmark v1.6 | Reference controls for Docker |
| CIS Kubernetes Benchmark | Reference controls for Kubernetes |
| NIST SP 800-190 | Application Container Security Guide |
| ENISA Cloud Baseline | Security in containers - European baseline |
| Cosign / Sigstore | Image signing and verification |
| Falco | Runtime security for containers |
| OPA Gatekeeper / Kyverno | Admission controllers for Kubernetes |