OpenStack Audit Checklist Exposes Tenant Risks in 8 CLI Checks

Run these checks first: config file ownership and permissions (640/750), TLS on every service endpoint, disabled admin_token with fernet as the token provider, per-project quotas, RBAC and the Neutron shared flag, and CADF audit logging. Flag orphaned resources before you touch anything else, then work through the prioritized checklist below and save every command output as an artifact.

---

TL;DR:

• Set configuration files to 640 and directories to 750, owned by service accounts; remove admin_token entirely and use Fernet tokens.
• Verify TLS on public and internal APIs, then confirm admin endpoints are unreachable from tenant networks and firewall rules match the endpoint catalog.
• Inspect Neutron RBAC targets for wildcard access, validate shared flags, and compare each project’s quotas with documented defaults; investigate unexplained expansions.
• Enable CADF across every service, confirm events include initiator, target, and action, and centralize logs in protected storage with documented retention.
• Cross-reference active virtual machines, volumes, and ports against disabled projects before remediation, and preserve timestamped configuration, quota, RBAC, and log exports as evidence.

---

Table of Contents

• Run This Checklist in One Pass
• Identity and Dashboard Checks: Config, Tokens, and CADF
• Compute, Block Storage, and Image Service Checks
• Networking Checks: RBAC, Shared Objects, and Quotas
• Logging and CADF: Enabling and Preserving Audit Evidence
• Practical Audit Runbook: Commands and Evidence Packaging
• Author Credibility and Planning an Audit Cycle
• OpenStack Audit Log Retention and Secure Storage
• Auditing Keystone Authentication and Authorization Flows
• Verifying API Endpoint Security and Exposure
• Reviewing User and Service Account Activity
• Automated Audit Reporting and Alerting
• Mapping OpenStack Controls to Compliance Standards
• What Actually Fails Most OpenStack Audits
• DevOps AI Toolkit: Audit Services and Automation Toolkits We Offer
• FAQ
• Sources

Run This Checklist in One Pass

We treat an OpenStack audit the same way we treat a production incident: read the state first, don’t assume anything. Here’s the order that catches the most problems with the least wasted motion.

1. Export the project list and owners. openstack project list --long and save the output as your baseline inventory.
2. Check config file ownership on every control node. stat the keystone, nova, cinder, glance, and neutron config directories.
3. Confirm TLS termination on every public and internal API endpoint, not just the public-facing ones.
4. Verify admin_token is absent from keystone.conf and that the token provider is fernet.
5. Pull quotas per project and compare against your documented defaults.
6. List RBAC policies and shared network/image flags, looking specifically for wildcard targets.
7. Export a sample of CADF events from each service’s notification stream.
8. Cross-reference active resources against disabled projects to catch orphaned VMs, volumes, and ports.

Escalate immediately if you find admin_token still enabled, TLS missing on an internal endpoint, or a wildcard RBAC entry on a production network. Those three findings tend to indicate a broader configuration drift problem, not an isolated miss.

Identity and Dashboard Checks: Config, Tokens, and CADF

Keystone is the first place auditors look, and it’s usually where the oldest configuration debt lives. Start with the file system, not the application.

• Confirm /etc/keystone/keystone.conf and related files are owned by the keystone service user, not root or a shared admin account.
• Set file permissions to 640 and directory permissions to 750. These values give the owner read and write access, the group read access, and block everyone else, which is the pass criteria OpenStack’s security guide specifies for identity configuration.
• Search the config for admin_token and remove it entirely rather than commenting it out; legacy admin tokens bypass normal authentication and are a known residual risk in older deployments.
• Confirm AdminTokenAuthMiddleware is not loaded in the pipeline.
• Verify the token provider line reads fernet, not uuid or pki, and that insecure_debug is set to false so error responses don’t leak sensitive data.
• Enable CADF notifications by setting notification_format=cadf and pull a sample event to confirm it carries initiator ID, target URI, and action fields.

Auditors generally expect configuration files locked to 640/750 for identity services because those permissions are the baseline that keeps credentials and signing keys out of reach of non-service accounts. If a config file comes back world-readable or owned by a personal account instead of the service user, that’s a finding you document and remediate before moving to the next service, not after.

For a deeper walkthrough of exporting these artifacts automatically rather than running each command by hand, our guide to automating OpenStack audit evidence collection covers the scripting side in more detail.

Compute, Block Storage, and Image Service Checks

Nova, Cinder, and Glance each carry their own slice of the same risk: who can read the config, and is traffic between services encrypted.

• Check ownership and permissions on nova.conf, cinder.conf, and glance-api.conf using the same 640/750 standard applied to Keystone.
• Confirm api_insecure=false in the Nova to Glance connection settings, which forces certificate validation rather than letting traffic pass over an unverified TLS channel.
• Verify Cinder’s backend credentials aren’t stored in plaintext inside a world-readable config, especially on multi-tenant storage backends.
• Pull lifecycle logs for instance creation, volume attach/detach, and image upload events, and confirm each service is emitting them in a format you can centralize.
• Check that each service’s audit middleware is actually enabled, since Keystone-level logging alone won’t show you who attached a volume to an instance in another project.

These three services generate the bulk of day-to-day resource activity, so gaps here show up later as unexplained orphaned volumes or images nobody can attribute to a project.

Networking Checks: RBAC, Shared Objects, and Quotas

Neutron’s RBAC model is where wildcard exposure most often hides, because a single shared=True flag can quietly open a network or image to every project in the cloud.

• List RBAC entries with openstack network rbac list and inspect each target tenant field for a wildcard *, which represents all projects rather than a named tenant.
• Cross-check any wildcard entries against your change records. If nobody can explain why a network is shared cloud-wide, treat it as an unintended exposure until proven otherwise.
• Pull quotas with openstack quota list --network and compare per-project limits against your documented baseline. Default limits often include a set number of security groups and security group rules per project, and projects with limits raised significantly above defaults deserve a second look.
• Review policy.yaml overrides in Neutron and confirm the oslo_policy settings match what’s documented, since an overridden policy file is easy to forget once it’s been patched for a one-off request.

Pro Tip: Run the RBAC export on a schedule, not just during audit week. Wildcard entries tend to get added during incident response and forgotten once the fire is out.

Logging and CADF: Enabling and Preserving Audit Evidence

CADF, the Cloud Auditing Data Federation format, standardizes audit events across OpenStack services so a reviewer can trace an action regardless of which component triggered it.

• Set notification_format=cadf in each service’s config, not just Keystone’s, and confirm the resulting events are being emitted.
• Validate that sample events carry the required fields: initiator, target URI, and the action taken (create, update, delete).
• Centralize events from every service into one log store rather than leaving them scattered across hosts, and document any opt_out settings that suppress specific event types.
• If you rely on a suppressed event category for a legitimate operational reason, write that exception down. An auditor will ask why it’s missing.

CADF events include initiator, target, and action fields that normalize activity across services, which is exactly the structure that SOC 2 and ISO 27001 reviewers expect to see in a compliance evidence package. Without it, you’re stitching together raw service logs by hand, and that rarely holds up under a formal review.

Practical Audit Runbook: Commands and Evidence Packaging

Once the checklist above turns up findings, the next job is making the evidence reviewable. Here’s the sequence we use to go from raw command output to a package a reviewer can actually work with.

1. Export project and quota data: openstack project list --long and openstack quota list --network per project, saved as timestamped CSV or JSON.
2. Pull RBAC state: openstack network rbac list -f json piped straight into your evidence folder.
3. Sample CADF events from each service’s notification queue and save a handful of representative entries per service.
4. Snapshot config file permissions across control nodes with a simple stat loop, rather than trusting memory.
5. Run a validation suite (Tempest or an equivalent test harness) against a staging environment to confirm the controls you documented actually hold under test conditions, a pattern we walk through in our Tempest validation guide.
6. Bundle configs, logs, RBAC exports, and any signed exception records into one directory a reviewer can open without chasing you for a missing file.

Pro Tip: Automate steps 1 through 4 with a scheduled script rather than running them manually before every audit cycle. Drift between audits is where most surprises come from.

Author Credibility and Planning an Audit Cycle

This checklist comes from production OpenStack operations work, not a vendor datasheet. James, who writes for our blog, focuses on OpenStack automation and audit tooling as part of our day-to-day consulting work.

• Audit cycles generally run Planning (2 weeks to 6 months before fieldwork) to Fieldwork to Reporting to Wrap-up, a cadence the OpenStack Security Guide recommends so inventory exports and access reviews are ready before reviewers show up.
• Prepare artifacts during Planning, not Fieldwork: config exports, RBAC lists, and quota reports should already exist by the time an auditor asks for them.
• Our OpenStack Troubleshooting Toolkit collects runbooks and validators operators reuse across audit cycles instead of rebuilding scripts each time.

OpenStack Audit Log Retention and Secure Storage

Retention policy is where a lot of audits quietly fail, not because the logs don’t exist but because nobody decided how long to keep them or where they live. CADF events, Keystone authentication logs, and per-service lifecycle logs each need a retention window that matches whatever compliance framework you’re working against, and that window needs to be written down somewhere other than one engineer’s memory.

Store audit logs outside the control plane they describe. If Keystone’s own host is compromised, logs sitting on that same host are worthless as evidence. Centralizing CADF events into a dedicated log store, separate from the services generating them, protects the evidence chain even if a single node is compromised.

Access to the log store itself needs its own review. Logs that document who did what are only useful if they can’t be quietly edited after the fact, so treat write access to the audit log store as sensitive as access to the services it monitors. Rotate and archive logs on a documented schedule rather than letting disk pressure decide retention for you, and confirm your archive format is still readable years later, not just at the moment you wrote it.

Document the retention period itself as part of your compliance package. A reviewer will ask how long you keep audit evidence before they ask to see a sample of it, and “however long the disk holds out” is not an answer that survives a formal review.

Auditing Keystone Authentication and Authorization Flows

Keystone handles both authentication (who you are) and authorization (what you’re allowed to do), and an audit needs to check both flows separately rather than assuming one implies the other.

On the authentication side, confirm fernet tokens are in use, that admin_token has been removed, and that token expiration settings match your organization’s session policy rather than a default left over from installation. Review the identity backends configured, whether that’s a local SQL backend or an LDAP integration, and confirm credentials aren’t being passed or logged in plaintext anywhere in that chain.

On the authorization side, pull the policy files Keystone enforces and compare them against what’s actually deployed. A policy file that’s been patched for a one-off exception and never reverted is one of the more common gaps we see, and it rarely shows up unless someone specifically diffs the deployed file against the documented baseline.

Trace a handful of real authorization decisions end to end: pick a user, a role assignment, and a resource action, and confirm the chain from role to policy to allowed action matches what you’d expect. This kind of spot check catches role assignments that have drifted from their original intent, which a simple file review won’t surface on its own.

Verifying API Endpoint Security and Exposure

Every OpenStack service exposes an API endpoint, and each one is a potential entry point if it’s reachable from somewhere it shouldn’t be. Start by pulling the full endpoint list with openstack endpoint list and checking which ones are marked public versus internal versus admin.

Confirm TLS terminates correctly on every public endpoint, not just the ones your team interacts with daily. Internal endpoints deserve the same scrutiny: an internal API reachable from a network segment outside your control plane is an exposure even if it’s never meant to face the internet.

Check that admin endpoints, in particular, aren’t reachable from general tenant networks. These typically carry elevated privileges, and segmentation mistakes here are disproportionately costly compared to a misconfigured public endpoint.

Review firewall rules and security group defaults around your control plane hosts to confirm they match the endpoint catalog rather than trusting that the catalog alone reflects reality. A stale firewall rule left open from a previous migration is a common way an endpoint ends up more exposed than its catalog listing suggests.

Reviewing User and Service Account Activity

Static configuration checks tell you how the cloud is supposed to behave. Account activity review tells you what’s actually happening, and the two don’t always match.

Pull a list of active users and service accounts per project, and flag any account that hasn’t authenticated in a defined window, say 90 days, as a candidate for deactivation. Dormant accounts with standing credentials are a common finding in older clouds, especially ones that have been through staff turnover without a corresponding access review.

Service accounts deserve particular attention because they often carry broad permissions by default and rarely get the same scrutiny as human users. Confirm each service account’s scope matches what it actually needs, and look for any account with project-admin or domain-admin privileges that was granted for a one-off task and never scaled back down.

Cross-reference account activity against your CADF event stream where possible. A service account that’s authenticating from an unexpected source, or at an unusual frequency, is worth a second look even if its permissions are correctly scoped.

Automated Audit Reporting and Alerting

Running this checklist by hand once a year catches point-in-time problems but misses drift that happens in between. Automating the recurring parts turns an annual audit into an ongoing control.

Script the export steps covered in the runbook above, config permission checks, quota pulls, RBAC listings, and CADF sampling, and run them on a schedule rather than only before a scheduled review. A weekly or monthly cron job that diffs current state against your documented baseline will catch a wildcard RBAC entry or a dropped TLS setting long before an external auditor does.

Alert on specific conditions rather than just logging them: admin_token reappearing in a config file, a new wildcard RBAC entry, a quota that’s jumped well past its documented limit, or a CADF stream that’s gone quiet. Each of those is a signal worth paging someone over, not just noting in a report nobody reads until next quarter.

Feed the output into whatever reporting format your compliance team already uses, whether that’s a dashboard, a scheduled PDF export, or a ticket queue. The goal is that findings surface on their own schedule instead of waiting for the next formal audit cycle to be discovered.

Mapping OpenStack Controls to Compliance Standards

PCI-DSS, HIPAA, SOC 2, and ISO 27001 each define their own control language, but the OpenStack-level evidence that supports them overlaps heavily: access control enforcement, encryption in transit, audit logging, and account activity review all map across multiple frameworks at once.

For PCI-DSS, the checks covered above around TLS enforcement, access control via RBAC, and detailed audit logging map directly to its requirements for protecting cardholder data environments and tracking access to systems that touch that data. HIPAA’s technical safeguards similarly lean on access controls, audit controls, and transmission security, which is effectively the same TLS, RBAC, and CADF evidence collected during a standard OpenStack audit.

Security hardening, including TLS, strict file permissions, and disabling legacy tokens, is a prerequisite most compliance frameworks assume before they even look at your logs, and clouds that skip the basic configuration checklist tend to fail on fundamentals rather than on anything framework-specific.

Build your compliance package around the artifacts this checklist already produces: config permission snapshots, TLS verification, RBAC exports, quota reports, and CADF samples. Label each artifact with the control it supports for the framework you’re mapping against, since the same evidence file often satisfies more than one requirement across different standards.

What Actually Fails Most OpenStack Audits

Most audit failures aren’t exotic. Shadow resources, undocumented ownership, and disabled projects that still have active VMs cause more findings than anything clever. Keystone logs alone miss resource-level activity, so enable per-service CADF. Fix admin_token and TLS gaps first: they’re the ones auditors flag hardest.

— James

DevOps AI Toolkit: Audit Services and Automation Toolkits We Offer

If this checklist surfaced more gaps than you have time to chase, our OpenStack / Kolla-Ansible Review runs this exact process against your environment in an artifact-driven review covering config permissions, TLS, RBAC, and CADF evidence. For teams that want the checklist as a reusable asset, our OpenStack Operations Toolkit packages runbooks and validators. Need it running continuously instead of once a year? Our managed OpenStack services take the audit cadence off your plate entirely.

Book an OpenStack review to get started.

FAQ

What is the recommended file permission for OpenStack configs?

The OpenStack Security Guide recommends 640 for configuration files and 750 for directories, owned by the service user rather than a shared or personal account. These settings give the owner read and write access while blocking general access, which is the baseline auditors check first.

Why should admin_token be disabled in Keystone?

Legacy admin tokens bypass normal authentication, which makes them a standing risk if a config file is ever exposed. OpenStack checklists call for removing admin_token entirely and using fernet as the token provider instead.

What is CADF and why does it matter for compliance?

CADF, the Cloud Auditing Data Federation format, standardizes audit events across OpenStack services so every action carries the same initiator, target, and action fields. Enabling notification_format=cadf produces the structured evidence that SOC 2 and ISO 27001 reviews typically expect.

How do I find wildcard RBAC entries in Neutron?

Run openstack network rbac list and inspect the target tenant field on each entry for a * character, which represents all projects rather than one named tenant. Any wildcard entry without a documented reason should be treated as unintended exposure.

How much does an OpenStack audit through DevOps AI Toolkit cost?

Our OpenStack / Kolla-Ansible Review is a one-off engagement covering config, TLS, RBAC, and CADF checks. For a self-serve option, the OpenStack Operations Toolkit is available.

Recommended

• Engineers: Automate OpenStack Security Audit Evidence, Log
• Debugging Keystone Identity and Authentication in OpenStack
• Debugging Heat Orchestration Stacks in OpenStack
• The Complete Infrastructure Audit Checklist for IT Teams