Enforce image signature and certificate validation by requiring signed images and trusted certificate checks in the image import and launch path. This stops unauthorised or tampered images from being used on compute hosts. Confirm that the image service, trust store, and deployment workflow all reject unsigned or untrusted images before you rely on it.
What validation has to happen in the OpenStack image path?
Enforcement is only real if the checks happen before an image is trusted for boot, not after a workload already starts. In practice that means the image service, the import workflow, and the launch path must all reject artefacts that fail signature verification or certificate trust checks. If any one of those stages bypasses validation, an attacker can still get a tampered image onto a compute host.
That also means you should treat image validation as a control path, not just a metadata check. The signing key, trust store, and verification logic need to be aligned, otherwise the platform may accept a technically signed image that is not chained to the certificate you intended to trust.
How do you make OpenStack reject untrusted images consistently?
Use a policy that requires signed images and trusted certificate validation at every place where an image can enter or move through the platform. The operational goal is simple: an image should either verify cleanly against the approved trust anchor or fail closed. That is the same discipline described in the Code Signing Security Guide, where signing controls only help when key protection, revocation, and validation are enforced together.
For OpenStack, the most important implementation detail is consistency. If Glance, a pipeline step, or a deployment tool caches or rewrites images without rechecking the signature and certificate chain, the system creates a bypass. That is why the trust store, CA material, and image metadata policy need to be managed as part of the same control surface rather than as separate admin tasks.
A mature deployment should also distinguish between image integrity and image provenance. Integrity answers whether the bytes changed; provenance answers whether the image came from the source you intended to trust. Container Image Security Guide is a useful parallel because the same failure pattern appears when teams verify content partially but do not enforce provenance at admission.
What should you verify before depending on the control?
Start by confirming that the image service rejects unsigned images, rejects signatures that do not chain to a trusted certificate, and fails closed when the trust store is missing or stale. Then test the full workflow, not just one API call: import, catalog, snapshot, replicate, and boot should all preserve the same enforcement outcome. If only one path validates, the control is incomplete.
You should also verify that certificate lifecycle operations are part of the process. A trusted signature is only useful while the signing certificate, chain, and revocation state remain current. The Machine Identity, PKI and Certificate Lifecycle Guide is relevant because it frames certificate handling as a lifecycle problem, not a one-time configuration task.
Where the trust root is external or shared across teams, check who can update it and how changes are approved. A compromised trust store is functionally equivalent to disabling validation, because the platform will accept whatever now matches the altered trust anchor.
Risk and Threat Considerations
Image signature validation fails when teams assume that signing alone proves trust. Attackers only need one weak link, such as an unprotected signing key, a stale trust store, or a deployment step that skips verification, to push a malicious or modified image into production.
Failure mechanism: The control breaks when the platform validates at ingest but not at launch, or when an attacker can alter the trust anchor, reuse an old certificate, or submit an image that is signed but not bound to the expected policy.
Impact: A tampered image can execute on compute hosts with the privileges of a legitimate workload, turning image trust into initial access, persistence, or lateral movement.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57, NIST SP 800-53 Rev 5, CSA Cloud Controls Matrix and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | 4 — Key Management throughout the Lifecycle | Image signatures rely on protected keys and certificate lifecycle control. |
| Recommendation — Protect signing keys and enforce lifecycle controls for certificate issuance, rotation, and revocation. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Signature and certificate trust depend on secure management of authenticators and related secret material. |
| SI-7 — Software, Firmware, and Information Integrity | Image signature verification is an integrity control for bootable artefacts. | |
| Recommendation — Rotate and protect signing credentials and related trust material on a defined lifecycle. Verify image integrity before deployment and reject artefacts that fail authenticity checks. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Trusted image validation depends on controlling who can sign, publish, and alter trust anchors. |
| Recommendation — Restrict signing and trust-anchor administration to approved roles with auditable change control. | ||
| OWASP ASVS | V11 — Cryptography | The question centers on certificate trust, signature verification, and cryptographic assurance. |
| Recommendation — Validate signatures with approved certificates and protect the cryptographic material used for trust decisions. | ||
Practitioner Guidance
What to verify: Prove that rejection happens at every path an image can take into production, including automation that copies or repackages images. A single successful bypass is enough to invalidate the control.
Decision rule: If the image can boot before signature and certificate checks complete, treat the deployment as noncompliant and fix the enforcement point before expanding use of the workflow.
What practitioners underestimate: Validation logic is often weaker in operational shortcuts than in the main API path, especially where teams mirror images, promote them across environments, or rely on cached artefacts.
Practitioner takeaway: The control is only trustworthy when OpenStack rejects untrusted images by default at every entry point, and when certificate lifecycle management is tight enough that yesterday’s trust is not silently treated as today’s trust.
Related resources from NHI Mgmt Group
- What is the difference between admission controller image signature validation and runtime-based validation in Kubernetes?
- What breaks when certificate trust or hash verification fails in digital signature validation?
- How do you test signature validation?
- How do you patch or mitigate CVE-2023-41991 (Apple Multiple Products Improper Certificate Validation)?