OpenStack Security Guide: Keystone, Nova, Neutron, Barbican

In an OpenStack cloud you are the cloud provider, so every control a hyperscaler runs for you (identity service hardening, API policy, hypervisor isolation, key management, audit) is yours to configure and yours to get wrong. OpenStack runs private clouds, research platforms and a large share of telecoms network function infrastructure, and the attack surface spans Keystone tokens and policy files, service account passwords in configuration files, the metadata service, Neutron security groups and the hypervisor boundary. This guide follows the shape of the official OpenStack Security Guide but uses current Keystone and Nova documentation for behaviour that has changed since that guide was written, notably the secure role-based access control (RBAC) defaults. It covers identity and access, privileged roles, service and application credentials, logging, and a hardening baseline with the community's own configuration checks. It is for operators, platform engineers and security architects running OpenStack.

Key takeaways

Adopt the new default roles and scopes. Keystone ships admin, manager, member, reader and service roles, and Nova documents new defaults as on by default since 2023.1; legacy "any admin anywhere" policy is the biggest authorisation risk in older clouds.
Service passwords in configuration files are your largest NHI estate. Every service's [keystone_authtoken] section holds a service user password; protect the files (640 or stricter) and give service users the service role, not admin.
Give applications application credentials, not user passwords. They delegate a subset of roles on one project, can expire, and by default cannot create further credentials.
Never run Barbican's simple crypto plugin in production. It stores the key encryption key in plain text in barbican.conf; use the PKCS#11 plugin with an HSM or another hardened back end.
Separate the four security domains. Public, guest, management and data networks need separate segments, and internal service traffic should use internal endpoints with TLS.

How identity and access work in OpenStack

Keystone, the Identity service, authenticates users and services and issues tokens that every other service (Nova compute, Neutron networking, Cinder block storage, Glance images, Swift object storage, Barbican key management) validates through keystonemiddleware. Each service then authorises the request against its own policy rules, which reference the roles in the token.

Identity sources: Keystone's SQL backend, LDAP, or external and federated identity (SAML 2.0 or OpenID Connect through a federation module). Many security compliance options only apply to the SQL backend, so LDAP and federated users rely on the source directory's controls. See the LDAP Security Deep Dive Guide.
Domains and projects: a domain contains users, groups and projects; a project (formerly tenant) owns resources. Role assignments bind a user or group to a role on a project, a domain or the system.
Scopes: tokens are scoped to a project, a domain or the system. Nova's documentation states that from 2026.2 (Nova 34.0.0) scope enforcement is mandatory and every Nova policy is project-scoped, so a system-scoped token receives 403 on the compute API.
Tokens: Fernet (the default) and JWT tokens are non-persistent bearer tokens; the Security Guide notes a default expiry of one hour and recommends the lowest value your long-running operations tolerate. Tokens can be revoked through the Identity API.
Multi-factor authentication: Keystone supports per-user MFA rules such as [["password", "totp"]], which requires both methods for a token. Federated users get MFA from their identity provider.

Role	Implies	Intended use	Risk if misused
`admin`	manager, member, reader	Cloud operators, system and deployment administration	With legacy policy, an admin role on any project acted as cloud-wide admin
`manager`	member, reader	Self-service management of users, groups, projects and role assignments within a domain (Keystone 2023.2 onwards), and project-level management in Nova	Domain manager can grant roles to anyone in the domain
`member`	reader	Project users who create and change resources	Normal blast radius of a project
`reader`	none	Read-only access; Keystone notes it deliberately does not expose sensitive data	Not a full auditor role for compliance
`service`	none (separate)	Service-to-service API calls, replacing `admin` for service users	Nova warns not to give it to human administrators

Admin roles and privileged access

Before the secure RBAC work, Nova's documentation records three structural problems: no distinction between global and project administrators, no read-only roles, and admin_or_owner checks that operators could not override. The legacy admin_only rule passed for an admin in any project. Clouds that still run legacy policy files carry those problems.

Turn on the new defaults: keep [oslo_policy] enforce_new_defaults = True (the documented default for Nova since 27.0.0) and remove overrides in policy.yaml that recreate the old behaviour. Test with the personas Nova documents: project reader, project member, project manager and admin.
Audit policy overrides: every line in a service's policy.yaml is a security decision. Keep overrides in version control with a reason per rule; regenerate a baseline with oslopolicy-sample-generator and diff after each upgrade.
Remove the bootstrap admin token: the Security Guide check Check-Identity-06 requires admin_token under [DEFAULT] in keystone.conf to be disabled; the shared token bypasses normal authentication.
Protect cloud administrators: federate administrator sign-in to the corporate identity provider with phishing-resistant MFA, or enforce Keystone TOTP rules for SQL users; use separate admin accounts; and restrict access to the admin API network.
Control host access: root on a controller or compute node bypasses all API policy (configuration files, database credentials, message queue). Treat SSH to infrastructure nodes as privileged access with its own controls. See the SSH Key Management Guide.
Account lockout and hygiene: for SQL users, set the [security_compliance] options: lockout_failure_attempts and lockout_duration against brute force (MITRE ATT&CK T1110), disable_user_account_days_inactive for dormant accounts, unique_last_password_count, minimum_password_age, password_regex and change_password_upon_first_use.

Integrations, API tokens and service accounts

Credential	Where it lives	Risk	Control
Service user passwords (`[keystone_authtoken]`, `[service_user]`, `[nova]` sections)	Configuration files on controllers and compute nodes	Readable files give API access as the service (T1552.001 Credentials In Files)	Ownership root:<service>, mode 640 (Security Guide checks 01 and 02); `service` role; unique password per service; rotate through deployment tooling
Database and message queue passwords	Same configuration files	Direct access to all service data, bypassing policy	Per-service database users; TLS to the database and RabbitMQ; network isolation in the management domain
User passwords in `clouds.yaml` or `openrc` files	Workstations, CI servers	Full user access from anywhere the API is reachable	Replace with application credentials
Application credentials	Applications, automation	Scoped to one project and a subset of roles	Expiry date, restricted (default), access rules where supported
Instance credentials from the metadata service or config drive	Inside guests	SSRF or guest compromise reads user data and injected secrets (T1552.005 Cloud Instance Metadata API)	Do not pass secrets in user data; use Barbican with application credentials
Fernet and credential encryption keys	`/etc/keystone/fernet-keys`, `credential-keys`	Anyone with the keys can forge tokens or decrypt stored credentials	Strict file permissions, scheduled rotation, distribution only to Keystone nodes

Application credentials

What they are: an ID and secret a user creates on one project, delegating a subset of that user's roles. Keystone hashes the secret, so it cannot be retrieved after creation; set expires_at so credentials do not live forever.
Restricted by default: a restricted application credential cannot create other application credentials or trusts. Keystone warns that --unrestricted lets a compromised credential regenerate itself; do not allow it outside tightly reviewed cases.
Access rules: narrow a credential to specific service API paths and methods. Each service using keystonemiddleware must set service_type in [keystone_authtoken] for access rules to work.
Lifecycle: application credentials belong to the user who created them; plan for what happens when that person leaves, and inventory them as non-human identities. See the Non-Human Identity (NHI) Guide.

Barbican

Barbican stores secrets, symmetric keys and certificates and backs features such as Cinder volume encryption and Glance image signature verification, often through the Castellan library. Its plugin choice decides how strong it is. The Security Guide states the simple crypto plugin is configured by default and keeps a single key encryption key in plain text in /etc/barbican/barbican.conf, so it is suitable only for development and testing. Production deployments should use the PKCS#11 crypto plugin with a hardware security module, or another secret store plugin backed by a hardened key manager. See the Cryptographic Key Management Guide.

Logging and detection

API audit: enable Keystone notifications in CADF format and the keystonemiddleware audit filter on service APIs so authentication events, role assignments and resource operations are recorded with initiator, target and outcome. Forward them through the notification bus to the SIEM.
Service logs: centralise Keystone, Nova, Neutron, Cinder and Barbican logs, and keep insecure_debug = false in keystone.conf (Check-Identity-07), because debug output can leak sensitive detail to clients.
Host logs: auditd and SSH logs from controllers, compute and network nodes, since host access bypasses API audit. See the Linux Logging and auditd for Defenders Guide.
Hypervisor signals: unexpected processes or crashes of QEMU, libvirt errors and SELinux or AppArmor denials on compute nodes can indicate guest escape attempts (T1611 Escape to Host).

Detection	Source
Role assignment of `admin` or `service` to a human user, or at domain or system scope	Keystone CADF notifications
Repeated failed authentications and account lockouts	Keystone logs and notifications
Creation of unrestricted application credentials or trusts	Keystone notifications
Service user tokens used from addresses outside the management network	keystonemiddleware audit, API logs
Changes to security group rules opening 0.0.0.0/0 to management ports	Neutron API audit
Changes to `policy.yaml` or service configuration files	File integrity monitoring on controllers
Barbican secret reads by unusual users or services	Barbican API audit

Metrics

Percentage of services running with new default policies and no legacy overrides.
Number of human users holding admin, and number holding service (target: zero).
Percentage of automation using application credentials with an expiry date.
Configuration files failing the Security Guide ownership and permission checks.
Age of the oldest Fernet primary key (rotation working).

Hardening baseline

The OpenStack Security Guide publishes per-service checklists. The table summarises the most important checks; the guide's own check IDs are given where they exist.

Service	Setting	Security Guide check
Keystone	Config files owned by keystone, mode 640 or stricter	Check-Identity-01, 02
Keystone	TLS on the Identity API	Check-Identity-03
Keystone	`max_request_body_size` at the default 114688	Check-Identity-05
Keystone	`admin_token` disabled; `insecure_debug = false`; `[token] provider = fernet`	Check-Identity-06, 07, 08
Nova	Config files root:nova, 640; `auth_strategy = keystone`; `www_authenticate_uri` over HTTPS; `[glance] api_insecure = false`	Check-Compute-01 to 05
Neutron	Config files root:neutron, 640; `auth_strategy = keystone`; HTTPS `www_authenticate_uri`; TLS on the API (`use_ssl` or a TLS proxy)	Check-Neutron-01 to 05
All services	Internal endpoints registered in the catalog and used for service-to-service traffic	API endpoint recommendations
Barbican	PKCS#11 or other hardened secret store, not simple crypto	Secrets management chapter
Compute nodes	sVirt with SELinux or AppArmor confinement of QEMU, IOMMU enabled for passthrough devices, minimal host packages	Hardening the virtualisation layers

Network design

Four security domains: the Security Guide defines public (untrusted, internet-facing APIs), guest (instance-to-instance traffic), management (service interaction, databases, message queue) and data (storage traffic). Bridge them only through controlled interfaces.
Endpoints: the Security Guide notes that components use public endpoints by default and recommends configuring internal URLs in the Identity service catalog so management traffic does not leave the management network.
Security groups and quotas: use Neutron security groups for instance traffic, keep the default group restrictive, and set quotas to limit resource exhaustion by a compromised project. Modifying security groups through the Compute API applies the change to all ports on an instance, so manage them through Neutron.
Hypervisor isolation: keep compute nodes patched for QEMU, KVM and microcode issues; the hypervisor is the boundary between tenants. See the KVM and libvirt Security Guide and the Hypervisor and Virtualisation Security Guide.

Rollout

Baseline: run the Security Guide checklists against every node and record failures; inventory role assignments, service users and application credentials.
Fix file and transport basics: permissions, TLS on all APIs, internal endpoints, TLS to database and message queue.
Policy migration in staging: enable new defaults, run your functional tests and tempest with each persona, then fix or document overrides.
Service users: give each service user the service role and remove admin where the release supports it; rotate their passwords.
Applications: move automation from user passwords in clouds.yaml to application credentials with expiry dates.
Barbican back end: migrate to an HSM-backed plugin before relying on encrypted volumes in production.
Rollback: keep the previous policy.yaml and configuration in version control; a policy regression can be reverted per service without redeploying.

Small private cloud or telecoms scale

Small private cloud: a single region with LDAP or federated identity, new default policies, TLS everywhere, application credentials, and the checklists applied through configuration management usually suffice.
Telecoms or multi-region: network function workloads bring SR-IOV and PCI passthrough (IOMMU and device isolation matter more), many automation identities from orchestrators, and stricter audit retention. Treat orchestrator credentials as tier 0 and segment the management domain per region.

Common misconfigurations

Legacy policy left in place after upgrades: an admin role on any project still means cloud-wide administration.
Service users with admin: a leaked Nova or Neutron service password becomes a cloud administrator credential.
World-readable configuration files: any local user or compromised process on a controller reads every service and database password.
Personal passwords in automation: clouds.yaml files with a human's password copied to CI servers and shared drives.
Barbican on simple crypto: encryption that anyone with the configuration file can undo.
Flat management network: guest or public networks able to reach RabbitMQ, the database or internal APIs.

Framework mapping

Control area	NIST SP 800-53 Rev. 5	MITRE ATT&CK addressed
Keystone identity, MFA, lockout	IA-2, AC-2, AC-7	T1078, T1110
Secure RBAC and policy	AC-6	T1098
Service passwords, application credentials, Fernet keys	IA-5	T1552.001, T1078.004
Barbican and key management	SC-12, SC-28	n/a
Security domains, TLS, internal endpoints	SC-7, SC-8	T1190
Hypervisor hardening	CM-6	T1611
CADF audit and log collection	AU-2	All of the above

Practitioner checklist

Run the OpenStack Security Guide checklists for Identity, Compute and Networking on every node.
Enable new default policies and scope enforcement; version-control and justify every policy.yaml override.
Disable admin_token and insecure_debug in Keystone; use Fernet tokens with scheduled key rotation.
Give service users the service role, unique passwords and 640 file permissions.
Replace user passwords in automation with expiring, restricted application credentials.
Configure [security_compliance] lockout and inactivity settings for SQL users, or federate to an IdP with MFA.
Run Barbican with an HSM-backed plugin in production.
Separate public, guest, management and data networks and use internal endpoints with TLS.
Send CADF audit events, service logs and host logs to the SIEM and alert on admin and service role grants.

OpenStack Security Guide: Hardening Keystone, Nova, Neutron and Barbican