Image security and scanning

Why container image security matters

Container images bundle your application, its runtime, and dependencies. In OpenShift, almost everything runs as a container, so compromised or vulnerable images become one of the main attack vectors. Image security focuses on:

• Preventing known vulnerabilities from entering the cluster
• Ensuring images come from trusted sources
• Ensuring images are not tampered with (integrity)
• Enforcing policies on what images are allowed to run

In OpenShift, these concerns are addressed with a combination of:

• Image scanning tools and registries
• Policy enforcement (admission controls, RBAC, SCC interactions)
• Image signing and verification
• Runtime controls (e.g., what images can do once running)

This chapter focuses specifically on images and scanning, not general cluster security.

Image registries and trust in OpenShift

OpenShift uses container registries as the main source of images:

• Internal OpenShift registry
• External registries (e.g., Quay.io, Red Hat registry, Docker Hub, private registries)

From an image security perspective you care about:

• Where images come from (trusted registry vs public/untrusted)
• How they are accessed (TLS, authentication)
• What controls exist on push/pull and vulnerability scanning

OpenShift itself does not scan all images by default; instead it integrates with registries and external scanners.

Common patterns:

• Use a curated internal registry that mirrors and scans external images
• Restrict workloads to images from approved registries only
• Use registry features like immutable tags, signed images, and automatic vulnerability scans

Types of image security scanning

Image scanning generally falls into these categories:

1. Vulnerability scanning
• Looks for known CVEs in OS packages, libraries, language runtimes
• Maps installed packages and image layers to vulnerability databases
• Produces reports with severities (Critical/High/Medium/Low)
2. Configuration and best-practice scanning
• Checks for insecure defaults:
• Running as root
• No user specified in Dockerfile or image metadata
• Privileged flags or excessive capabilities
• Cleartext secrets in environment variables or labels
• Often integrated with policy engines
3. Malware / content scanning
• Looks for malicious binaries, known malware signatures, unexpected tools (e.g., crypto miners)
4. Software composition analysis (SCA)
• Understands all dependencies (including application libraries) and their licenses and vulnerabilities

Most OpenShift environments start with vulnerability and configuration scanning, then mature towards SCA and more advanced content scanning.

OpenShift-native image security components

OpenShift offers built-in and integrated capabilities focused on images:

Internal registry metadata and imagestreams

OpenShift tracks image metadata via:

• ImageStream objects, which reference actual image manifests
• Image labels and annotations (e.g., build information, source, commit)

While ImageStream itself doesn’t scan images, it offers:

• A central place to reference trusted images inside the cluster
• A way to control promotion (e.g., “only promote images that passed scans”)

Policies and automation can use image streams as control points: when a new image tag appears, trigger a scan and only then allow promotion to a “prod” tag.

OpenShift compliance with Red Hat images

Using Red Hat-certified base images is a core part of image security on OpenShift:

• Red Hat images are:
• Built from supported, curated components
• Regularly updated with security fixes
• Often pre-scanned and shipped with advisories (RHSA)

Organizations commonly have policies such as:

• All custom images must be built FROM a Red Hat UBI / RHEL base image
• Upstream community images from public registries are not allowed in production unless rebuilt and scanned internally

Integrating vulnerability scanners with OpenShift

OpenShift does not mandate a specific scanner; instead, it integrates with common image security tools, such as:

• Red Hat Quay Security Scanner (Clair-based)
• Red Hat Advanced Cluster Security (ACS)
• Trivy, Anchore, Aqua, Twistlock, etc.

Key integration points:

1. Registry integration
• Scanner is attached to a registry (e.g., Quay, external registry)
• Each push triggers a scan and stores results alongside the image
• OpenShift pulls images that are already scanned
2. Cluster-level integration
• An operator or controller runs in the cluster
• Periodically scans images referenced by Pods and ImageStreams
• Writes scan results as Kubernetes/OpenShift resources or annotations
3. Admission control
• Webhooks or ACS policies enforce:
  “Do not allow deployment of images with Critical vulns,” or
  “Only allow images with a minimum scan score.”

Technically, this is controlled by:

• Validating admission webhooks
• Policies in tools like ACS (Central) that evaluate image metadata at deploy time

Image scanning workflows in OpenShift

Typical workflows combine CI/CD and OpenShift capabilities.

Build-time scanning (shift-left)

Scan images before they reach the cluster:

1. CI pipeline builds an image (e.g., using OpenShift Builds, Tekton pipelines)
2. Image is pushed to registry (internal or external)
3. Scanner runs automatically and produces a report
4. Pipeline inspects the result and:
• Fails the build if vulnerabilities exceed a threshold
• Annotates the image with scan info (e.g., security.scan.status=passed)
5. Only “passed” images are tagged for deployment to production

Benefits:

• Vulnerabilities are caught early
• Developers see scan results as part of their pipeline feedback
• Reduces noise in production clusters

Deployment-time scanning (admission control)

Scan or check at deploy time:

1. A user or pipeline submits a Deployment, DeploymentConfig, etc.
2. OpenShift admission plugins/webhooks inspect the referenced image(s)
3. Policy is applied:
• If the image has no recent scan, force a scan or block deployment
• If scan results are above thresholds (e.g., Critical vulns present), deny admission
• If image is untrusted (registry not on the allow-list), deny or require exception approval

Deployment-time checks ensure that only compliant images can run, even if something slipped through CI.

Continuous re-scanning and drift handling

Vulnerabilities are discovered over time, so images can become “more vulnerable” after they are deployed.

Common pattern:

1. Periodic re-scans of:
• Images stored in registries
• Images running in the cluster
2. When new Critical vulnerabilities are found:
• Raise alerts
• Mark images as non-compliant
• Optionally trigger:
• Automated rebuilds
• Automated redeployments
• Quarantine or blocking of further deployments using that tag

OpenShift itself doesn’t do all of this out of the box; this is usually implemented with integrated products (e.g., ACS) or custom automation.

Policies for image usage in OpenShift

Image security requires clear policies on what images are allowed and under what conditions.

Typical policies:

1. Registry allow/deny lists
• Only allow images from:
• Internal enterprise registry
• Red Hat registries
• Deny or restrict public registries in production namespaces
2. Tagging conventions
• Disallow :latest in production deployments
• Require immutable, versioned tags (e.g., 1.2.3, 2024-06-01-build45)
• Promote images along environments using tags (dev → qa → prod)
3. Base image standards
• Only specific base images are allowed
• No images built from “unknown OS” or multi-stage builds without a known final image
4. Vulnerability thresholds
• Non-prod:
• Allow Medium/Low vulnerabilities
• Block Critical without exception
• Prod:
• Block Critical and High vulnerabilities
• Require justification/approval for any exceptions
5. Runtime constraints linked to image properties
• If an image runs as root or has privileged flags, it is:
• Blocked, or
• Only allowed in specific, tightly controlled namespaces

These policies are surfaced through:

• Admission webhooks / ACS policies
• RBAC + SCCs controlling which roles can deploy which types of images
• Namespace-level restrictions and labels

Using image signatures and trust in OpenShift

Image scanning checks for vulnerabilities, but not necessarily who built the image or whether it was tampered with.

Image signing and verification add:

• Authenticity: who signed the image
• Integrity: the image has not changed since signing

Approaches commonly used with OpenShift:

1. Registry-based signatures
• Sign images at build or release time using tools like:
• cosign
• Podman signing (sigstore, GPG-based signing)
• Signatures are stored in the registry or in a separate signature store
2. Cluster-enforced verification
• Admission policies check:
• Is this image signed?
• Is the signature issued by a trusted key/identity?
• Does the signature match the expected subject (e.g., CI system, specific team)?

Typical policy examples:

• Any image deployed to prod namespace must:
• Be signed by the organization’s CI service account
• Have a valid, unexpired signature
• Have a matching digest and tag

This complements scanning: a scanned and signed image is both securely built and verifiably approved.

Practical best practices for image security and scanning on OpenShift

These practices are specific to working with OpenShift clusters and pipelines:

1. Standardize on base images
• Use Red Hat UBI / RHEL images where possible
• Maintain a small set of organization-approved base images
• Regularly rebuild base images with security updates
2. Automate everything in CI/CD
• Add scanning steps to OpenShift Pipelines (Tekton) or your external CI
• Fail builds on policy violations, not just warn
• Push only “passed” images to prod-facing registries or imagestream tags
3. Use ImageStreams as security gates
• Dev pipeline pushes to myapp:dev
• After scanning, approved images are retagged to myapp:qa or myapp:prod
• Deployments in production reference only :prod tags
4. Protect namespaces with admission policies
• Stricter policies in production projects:
• Only certain registries allowed
• No :latest tags
• Required minimum scan level and signature
• Less strict but still scanning-enforced policies in dev/test
5. Monitor and respond to new vulnerabilities
• Enable continuous or scheduled scans of:
• All images in internal registries
• All images currently running in clusters
• Integrate results with:
• Alerting (e.g., OpenShift monitoring stack)
• Ticketing systems (automatic tickets for Critical findings)
• Rebuild/redeploy automation
6. Educate developers
• Document which base images to use
• Provide sample Dockerfile/Containerfile templates aligned with policies
• Make scan reports accessible and understandable to teams

Example: high-level secure image pipeline on OpenShift

A typical secure pipeline might look like this:

1. Developer pushes code to Git.
2. Tekton pipeline in OpenShift:
• Builds container image using approved base
• Runs unit/integration tests
• Pushes image to internal registry under myapp:build-<id>
• Triggers image vulnerability scan
3. Scanner produces report:
• If Critical/High vulnerabilities exist → pipeline fails, no promotion
• If acceptable → image is signed and retagged:
• myapp:dev for dev environment
4. Promotion to qa and prod:
• Additional gating (e.g., performance tests, manual approval)
• Final scan and signature verification
• Tagging to myapp:prod
5. OpenShift prod cluster:
• Admission controllers verify:
• Image comes from internal registry
• Image digest matches signed artifact
• Scan metadata meets policy
• Only then the deployment is admitted

This combines scanning, signing, and cluster policies to provide end-to-end image security for workloads running in OpenShift.