Set image visibility to private or shared only for the tenants that need it, and review who can change image metadata. Publicly visible images can expose untrusted or malicious base images to every tenant, so administrators should check Glance image visibility settings and remove public access unless there is a clear operational need.
How to keep OpenStack Glance images from becoming tenant-wide public assets
Image visibility in Glance is an access-control decision, not just a convenience setting. If an image is public, every tenant can discover and launch it, so the safest default is to keep images private unless there is a deliberate shared-use requirement. That also means treating image metadata changes as a controlled action, because visibility often changes through metadata updates.
The practical rule is to publish only what is meant to be reused broadly. Shared images should be limited to named tenants or project groups that actually need them, while private images should remain confined to their owner or the operating team. This is especially important for base images, because a bad image can spread faster than a bad workload if many tenants consume it.
Administrators should also verify that the image catalog and role assignments are aligned. If users can create, modify, or relabel images without review, a tenant can accidentally or intentionally widen exposure. The control point is therefore both the visibility flag and who is allowed to change the image record that drives that flag.
What actually makes a public image risky
A public image turns Glance into a distribution point for trust, so any image quality problem becomes multi-tenant risk. An untrusted or malicious base image can carry unwanted services, weakened defaults, embedded access paths, or hidden tooling into every project that launches it. That is why image sharing should be treated like software release approval, not like a simple catalog preference.
The first thing to check is whether the image is intended for tenant-wide consumption or whether it was exposed by mistake. If the image is meant to be a general platform standard, validate its source, provenance, and owner approval. If it is not meant for broad use, change the visibility back to private or project-scoped shared access and confirm that the policy is consistent across the catalog.
NIST SP 800-190 Container Security is useful here because it treats image trust, registry exposure, and runtime inheritance as a security issue, not a packaging detail. The same operational lesson applies to OpenStack images: once a base artifact is broadly visible, the blast radius is determined by who can consume it.
How to review Glance settings without breaking legitimate reuse
Start by inventorying which images are public, which are shared, and which tenants can currently consume them. Then confirm whether each public image has a business reason to be public, such as a standard operating image or a controlled golden image used across projects. If there is no clear reason, reduce visibility rather than keeping it open by default.
Next, review who can update image metadata, because visibility, ownership, and launch behavior are governed through metadata fields. Limit that ability to trusted administrators or image curators, and require a review step for changes that widen access. That prevents a routine edit from turning a private image into an organisation-wide asset.
NIST Cybersecurity Framework 2.0 is a useful companion for this control because the issue sits at the intersection of governance, access control, and configuration management. NIST SP 800-53 Rev 5 Security and Privacy Controls also maps well to the need to manage access, protect system integrity, and control configuration changes that can expose images more widely than intended.
Risk and Threat Considerations
Public images create a trust-boundary problem because any tenant can launch them without a separate approval step. If the image is compromised, stale, or simply misconfigured, the exposure is no longer confined to one project. The risk increases when teams assume that “shared” means “safe” and stop validating provenance, ownership, and metadata changes.
Failure mechanism: An image becomes public through default settings, accidental metadata changes, or overly broad permissions, and tenants start consuming it as if it were approved platform content. Once that happens, the image can propagate insecure defaults or hostile content across multiple projects.
Impact: The likely outcome is tenant-wide exposure, inconsistent baselines, and a larger blast radius if the image contains malware, backdoors, or unsafe configuration. In the worst case, one exposed image becomes a repeatable compromise path for every tenant that trusts it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Restricts who can consume public or shared images. |
| CM-3 — Configuration Change Control | Image visibility changes are configuration changes that need review. | |
| Recommendation — Enforce image access rules so only approved tenants can launch or view each image. Require review before changing image metadata or visibility settings. | ||
| NIST CSF 2.0 | PR.AA-05 — Least Privilege | Limits image exposure to only the tenants that need access. |
| Recommendation — Apply least privilege to image visibility and sharing scope. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Supports restricting image visibility to approved tenants only. |
| Recommendation — Limit image access to the tenants and roles that actually require it. | ||
Practitioner Guidance
What to verify: Confirm the current visibility state for every production image, then verify whether each public or shared image has an explicit business owner and approval reason. If you cannot name the owner or justification, treat that image as a control gap.
Common mistake: Teams often focus on who can launch instances and overlook who can alter the image record itself. If metadata edits are not tightly governed, visibility drift can re-open images that were previously intended to be private.
Practitioner takeaway: The safest operating model is private by default, shared by exception, and public only when the image is intentionally part of a governed platform standard.
Related resources from NHI Mgmt Group
- Guide: Cloud Misconfiguration Guide
- How can organizations prevent NHI-related breaches?
- How do you prevent sensitive data being stored in OpenStack resource metadata?
- How do you prevent a GKE control plane from being publicly accessible?
- How do you prevent Amazon EC2 AMIs from being shared publicly?