Skip to content
DevOps AI ToolKit
Newsletter
All guides
AI for OpenStack By James Joyner IV · · 11 min read

Hardening Glance Image Import With AI in OpenStack

How to lock down Glance interoperable image import, web-download, and conversion so tenants can't smuggle bad images in, with AI helping you audit the policy.

  • #openstack
  • #ai
  • #glance
  • #security
  • #images

Image import is the soft underbelly of a lot of OpenStack clouds. The same feature that lets your tenants conveniently pull a cloud image from a URL is the feature that, misconfigured, lets them point Glance at an internal metadata endpoint, smuggle in an image format your hypervisor will happily convert and run, or chew through disk on the conversion host. I’ve cleaned up a couple of clouds where “we enabled web-download because it was convenient” turned into a security review finding. Here’s how I harden Glance import now, and how AI helps me audit the configuration without ever trusting its verdict blindly.

The Import Methods and Their Blast Radius

Modern Glance has the interoperable image import workflow with several methods, and each carries different risk:

glance import-info
openstack image import --help

The methods you’ll see are typically glance-direct (stage then import), web-download (Glance fetches a URL), and copy-image (replicate across stores). web-download is the one that keeps me up at night, because Glance — a service often running with network access to internal endpoints — is now making outbound HTTP requests to a URL a tenant supplied. Without restrictions, that’s a server-side request forgery primitive. Check what’s enabled:

grep -A5 'image_import_opts\|allowed_ports\|disallowed_uris' /etc/glance/glance-image-import.conf

The openstack category collects the related Glance playbooks if you want the broader image-management context.

Locking Down web-download

The defenses for web-download live in glance-image-import.conf. You restrict which URI schemes and hosts are reachable and explicitly block the dangerous internal ranges:

[import_filtering_opts]
allowed_schemes = ['https']
disallowed_ports = [22, 23, 3306, 5432]
disallowed_uris = ['^.*169.254.169.254.*$', '^.*metadata.*$']

Blocking 169.254.169.254 matters because that’s the cloud metadata endpoint; if a tenant can make Glance fetch from it, they may exfiltrate credentials the Glance host can reach. Forcing https and blocking plaintext schemes prevents a class of internal-service probing. This is allow-listing in spirit: be restrictive and open up only what you need.

Prompt: “Here is my glance-image-import.conf import_filtering_opts section and the list of enabled import methods. Audit it for SSRF exposure: can web-download reach internal services, the metadata endpoint, or non-TLS URLs? List each gap and the minimal config change to close it. Rank gaps by severity. Treat anything that lets Glance reach 169.254.169.254 as critical. Do not propose changes to anything outside the filtering config.”

Output: It flagged that allowed_schemes permitted http (medium), that no disallowed_uris entry blocked link-local ranges (critical), and that an internal artifact host was reachable. It ranked the metadata-endpoint gap critical and proposed the exact regex additions, while noting the regexes should be tested because a sloppy pattern can be bypassed.

That SSRF audit is precisely where AI earns its keep — it reads a config block and enumerates exposure faster than I can. But I verify every proposed regex against actual test URLs, because the model’s own caveat is right: a filter that looks like it blocks the metadata endpoint but has a bypassable pattern is worse than no filter, since it creates false confidence.

Controlling Conversion and Format Risk

Glance can convert image formats during import (the image_conversion plugin), and conversion runs on a host, consuming CPU and disk and parsing tenant-supplied files. Two hardening moves: restrict the formats you accept, and bound the conversion resources.

grep -A6 'image_conversion\|inject_image_metadata' /etc/glance/glance-image-import.conf

Decide deliberately which disk_formats you allow in glance-api.conf — every format you accept is an attack surface for the conversion/parse path. If you don’t need vmdk or vhd, don’t allow them. And ensure the conversion host has bounded scratch space so a giant or malformed image can’t fill the disk.

Pro Tip: Have the AI list every disk and container format you currently allow against the formats your hypervisor actually needs, and propose removing the rest. Reducing accepted formats is the cheapest attack-surface reduction in Glance, and a model is great at spotting the ones you enabled years ago and forgot.

Signing and Provenance

For a real trust story, pair import hardening with image signature verification so the cloud only boots images whose signatures validate against a Barbican-stored certificate. That’s a deeper topic, but the principle connects: importing an image safely is only half the job; verifying it hasn’t been tampered with is the other half. When I’m reviewing whether a tenant’s imported image should be trusted, I’ll have Claude summarize the image properties and signature metadata, then verify the signature chain myself before marking anything trusted.

Auditing Who Can Import What

Finally, the policy layer. Import is governed by policy.yaml, and an over-permissive policy means any tenant can use the riskiest methods. Read it:

grep -i import /etc/glance/policy.yaml

You generally want to restrict copy-image and the broader import operations to roles that need them rather than every member. AI is useful for diffing your policy against the default and flagging where you’ve granted import rights more broadly than intended — a fast cross-read that I then confirm against your actual role assignments. I keep these audit prompts in the prompt workspace.

Conclusion

Glance image import is a convenience feature with a security-feature-sized blast radius. web-download is an SSRF primitive unless you constrain its schemes, ports, and URIs; conversion is an attack surface unless you bound formats and resources; and the whole thing is only as tight as your policy.yaml. AI is excellent at the audit work — enumerating SSRF gaps, listing unused formats, diffing policy — and that’s exactly where I use it. But every regex it proposes gets tested against real URLs, and every “this is blocked” claim gets verified, because in security a confident-but-wrong filter is worse than none. The model audits; you verify and apply. More Glance prompts are in the prompts library.

Free download · 368-page PDF

Download the Free 500-Prompt DevOps AI Toolkit

500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.

  • 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
  • Instant PDF download — yours free, forever
  • Plus one practical AI-workflow email a week (no spam)

Single opt-in · unsubscribe anytime · no spam.