Security¶

Authentication: Keystone¶

Keystone is the central identity service for all OpenStack components:

Feature	Details
Auth backends	SQL (local), LDAP, Active Directory, SAML 2.0, OpenID Connect
Token types	Fernet (symmetric, ephemeral), JWT (asymmetric)
Token scopes	Project-scoped, domain-scoped, system-scoped
Federation	Mapping external identity groups to Keystone roles/projects
MFA	TOTP and application credentials with MFA rules

graph TB
    subgraph Users
        Admin["Cloud Admin"]
        Tenant["Tenant Admin"]
        App["Application / Service"]
    end
    subgraph Keystone["Keystone Identity"]
        AuthN["Authentication\n(SQL/LDAP/OIDC)"]
        Token["Token Engine\n(Fernet/JWT)"]
        Policy["Policy Engine\n(policy.yaml)"]
        Catalog["Service Catalog"]
    end
    subgraph Services["OpenStack Services"]
        Nova["Nova"]
        Neutron["Neutron"]
        Cinder["Cinder"]
        Glance["Glance"]
        Swift["Swift"]
    end
    Admin --> AuthN
    Tenant --> AuthN
    App --> AuthN
    AuthN --> Token
    Token --> Policy
    Policy --> Catalog
    Catalog --> Services

Keystone Hardening¶

Rotate Fernet keys regularly (keystone-manage fernet_rotate)
Set short token lifetimes (1 hour for unscoped, 12 hours for scoped)
Disable the admin_token auth method in production
Enforce password complexity and rotation policies
Use scoped tokens (never unscoped) for API access
Enable audit middleware (CADF format) for all Keystone operations
Set file permissions on /etc/keystone/keystone.conf to 0600

Authorization: RBAC and Policy¶

Role-Based Access Control¶

OpenStack uses a policy engine (policy.yaml per service) to enforce RBAC:

Default Role	Scope	Typical Permissions
`admin`	System	Full access across all projects
`member`	Project	Create/manage resources in own project
`reader`	Project	Read-only access to project resources
Custom roles	Variable	Fine-grained per-service permissions

Project Isolation¶

Projects provide hard multi-tenancy boundaries:

Each project has isolated resources (VMs, networks, volumes, images)
Users can belong to multiple projects with different roles per project
Quotas enforce resource limits per project
Network namespaces prevent cross-project traffic

Secrets Management: Barbican¶

Barbican is OpenStack's key management service:

Capability	Description
Symmetric keys	AES encryption keys for Cinder volumes and Swift objects
Asymmetric keys	RSA/EC key pairs for TLS and signing
Certificates	X.509 certificate storage and lifecycle
Passphrases	Generic secret storage
HSM integration	PKCS#11 backends (Thales nCipher, AT&T ATAE)

Barbican Best Practices¶

Use the KMIP or Dogtag backend for enterprise deployments
Restrict API access via policy.json
Enable secret ACLs for cross-project secret sharing
Store TLS certificates and private keys in Barbican (not on filesystem)
Integrate with cert-manager for automated certificate lifecycle

Network Security: Neutron¶

Security Groups¶

Neutron security groups act as distributed stateful firewalls applied at the port level:

# Default-deny security group with explicit allow rules
openstack security group rule create --protocol tcp --dst-port 443 \
    --remote-ip 10.0.0.0/8 allow-https my-security-group

Default policy: deny all ingress, allow all egress
Stateful connection tracking (established connections auto-allowed)
Support for remote groups (allow traffic from another security group)
Port security and anti-spoofing enabled by default

Network Isolation¶

Mechanism	Level	Use Case
Projects	L2/L3	Hard tenant isolation
VLANs	L2	Simple network segmentation
VXLAN/GRE	L2 overlay	Scalable multi-tenant isolation
SR-IOV	L2	Hardware-level NIC partitioning
OVS/DPDK	L2/L3	High-performance programmable switching

Encryption¶

TLS Everywhere¶

Encrypt all inter-service communication:

API endpoints: TLS termination at HAProxy/Nginx, pass-through to services
RabbitMQ: TLS for all AMQP connections between services
MySQL/Galera: TLS for database connections and replication
Memcached: SASL authentication with TLS
Etcd: TLS for all client and peer connections

Encryption at Rest¶

Service	Encryption Method
Cinder	LUKS encryption via `encrypt_key_id` (Barbican integration)
Swift	At-rest encryption with Barbican-managed keys
Nova	Encrypted ephemeral storage (LUKS)
Glance	Image encryption (less common; rely on Cinder for volume-backed instances)

Compliance and Audit¶

CIS Benchmarks for OpenStack¶

CIS OpenStack Benchmark covers:

API endpoint configuration and TLS enforcement
Keystone hardening (token lifetimes, password policies)
Network security (security groups, segmentation)
File permissions (config files set to 0600/0640)
Database security (Galera TLS, restricted access)
Logging and monitoring (CADF audit events)

Audit Logging¶

Keystone CADF events: Track authentication, token operations, role assignments
Nova audit: Instance creation/deletion, metadata changes
Neutron audit: Security group changes, network creation
Centralized logging: Forward to ELK/Loki/Grafana for analysis

Hardening Checklist¶

Known Pitfalls¶

Pitfall	Risk	Mitigation
`admin_token` enabled	Unauthenticated admin access	Disable in production
Unencrypted RabbitMQ	Inter-service credential interception	Enable TLS on all AMQP connections
Overly broad security groups	VM exposure to unauthorized traffic	Default-deny with explicit allow rules
Unrotated Fernet keys	Compromised token encryption	Regular key rotation schedule
Shared MySQL credentials	Database access escalation	Per-service accounts with least privilege
No audit logging	Undetected unauthorized actions	Enable CADF events, centralize logs