OpenStack security depends on protecting control-plane APIs (Keystone, Nova, Neutron, Cinder, Glance), enforcing role boundaries, securing inter-service traffic, and hardening hypervisor hosts. A defense-in-depth approach is essential for production deployments.
¶ 1) Lock Down Identity and API Access
- Enforce least-privilege roles: Use domain-scoped and project-scoped roles
- Multi-domain isolation: Separate admin, service, and user domains
- Role hierarchy: Implement custom roles with minimum permissions
- Audit role assignments: Regularly review role grants and inheritances
- Federated identity: Integrate with enterprise IdP (SAML, OIDC, LDAP)
- MFA for admin users: Require multi-factor authentication for privileged accounts
- Token policies: Configure reasonable token expiration (default: 1 hour)
- Disable legacy auth: Remove insecure password-based auth methods
# List all endpoints
openstack endpoint list
# Review user roles
openstack role assignment list
# Check for admin users
openstack user list --domain default | grep admin
- Restrict public API exposure: Use firewall rules to limit API access
- API rate limiting: Configure rate limits to prevent DoS
- Validate API input: Enable input validation on all endpoints
- Monitor API access: Log and alert on unusual API patterns
- Protect service credentials: Use file permissions (chmod 600) for config files
- Rotate passwords regularly: Implement credential rotation schedules
- Use Barbican for secrets: Store sensitive data in OpenStack Key Manager
- Avoid plaintext passwords: Use application credentials or tokens
- Enable TLS everywhere: Encrypt all service endpoints (internal and public)
- Use strong cipher suites: Configure TLS 1.2+ with modern ciphers only
- Certificate management: Use valid certificates from trusted CAs
- Regular certificate rotation: Automate certificate renewal
# Review service users
openstack user list --service
# Check service endpoints
openstack endpoint show keystone
# Verify TLS configuration
grep -R "https" /etc/nova /etc/neutron /etc/cinder 2>/dev/null | head -20
- Dedicated service accounts: Create separate users for each service
- Strong service passwords: Use complex, randomly generated passwords
- Restrict service permissions: Grant minimum required roles
- Audit service access: Monitor service account activity
- RabbitMQ TLS: Enable TLS for AMQP connections
- Restrict queue access: Bind RabbitMQ to management network only
- Authentication required: Enable RabbitMQ authentication
- Monitor queue health: Watch for unusual message patterns
- MySQL/MariaDB TLS: Encrypt database connections
- Restrict database access: Bind to private interfaces only
- Strong database passwords: Use complex credentials
- Regular backups: Implement encrypted backup procedures
# Check database connectivity
sudo ss -tulpn | grep -E ':3306|:5432'
# Review MySQL users
mysql -u root -e "SELECT user, host FROM mysql.user;"
# Check RabbitMQ status
sudo systemctl status rabbitmq-server
¶ 3) Harden Hypervisor and Tenant Isolation
- Harden hypervisor OS: Apply security baselines to compute nodes
- Restrict libvirt access: Limit libvirt socket permissions
- Secure VM images: Validate and scan instance images
- Monitor compute logs: Watch for unusual VM activity
# List security groups
openstack security group list
# Review network segmentation
openstack network list
openstack subnet list
# Check firewall rules
openstack security group rule list
- Default deny security groups: Start with restrictive rules
- Network segmentation: Use separate networks for management, storage, tenant
- VLAN/VXLAN isolation: Enable tenant network isolation
- Router security: Restrict router access and floating IPs
- Encrypt volumes at rest: Use LUKS or provider encryption
- Secure backup storage: Encrypt and restrict backup access
- Access control lists: Implement share-level permissions (Manila)
- Audit storage access: Monitor volume attach/detach events
- Validate uploaded images: Scan for malware and vulnerabilities
- Restrict image sharing: Limit public image visibility
- Sign images: Use image signing for trusted images
- Regular image updates: Patch base images regularly
¶ 4) Network Security and Segmentation
- Isolate management traffic: Separate VLAN for OpenStack services
- Firewall rules: Restrict access to service ports
- Jump host access: Require bastion host for admin access
- No public exposure: Keep management network private
# Check network configuration
openstack port list
# Review router configuration
openstack router list
# Audit floating IPs
openstack floating ip list
- Security group defaults: Apply restrictive default security groups
- Network policies: Implement tenant network isolation
- Floating IP controls: Restrict floating IP allocation
- Egress filtering: Control outbound tenant traffic
- Dedicated storage VLAN: Isolate storage traffic (Cinder, Swift)
- iSCSI/Fibre Channel security: Implement CHAP authentication
- Encryption in transit: Enable TLS for storage protocols
- Access controls: Restrict storage network to compute nodes
¶ 5) Monitoring, Auditing, and Compliance
- Enable audit logging: Configure OpenStack audit middleware
- Centralize logs: Forward to SIEM or log management platform
- Log retention: Define retention policies for compliance
- Structured logging: Use JSON format for easier analysis
# Review OpenStack logs
sudo tail -f /var/log/nova/nova-api.log
sudo tail -f /var/log/keystone/keystone.log
# Check for failed authentications
grep -i "failed\|denied\|unauthorized" /var/log/keystone/*.log | tail -20
# Monitor resource usage
openstack usage show --project <project-id>
- Alert on auth failures: Detect brute force attempts
- Monitor resource quotas: Alert on quota exhaustion
- Track configuration changes: Audit OpenStack config modifications
- Watch for anomalous API calls: Detect unusual patterns
- OpenStack Security Guide: Follow official security recommendations
- CIS OpenStack Benchmark: Apply Center for Internet Security guidelines
- OSSTMM testing: Perform security testing using OSSIM methodology
- Regular penetration testing: Test cloud infrastructure annually
¶ Verification Commands
# List all endpoints and verify HTTPS
openstack endpoint list | grep -v https
# Check for insecure configurations
grep -R "transport_url\|connection\|auth_url\|password" /etc/nova /etc/neutron /etc/cinder /etc/glance 2>/dev/null | grep -v "#" | head -30
# Verify service ports
sudo ss -tulpn | grep -E ':5000|:8774|:9696|:9292|:35357|:5672|:3306'
# Check TLS configuration
openssl s_client -connect localhost:5000 -tls1_2 </dev/null 2>/dev/null | head -10
# Review security groups
openstack security group list
openstack security group rule list --dst-port 22
# Audit admin users
openstack user list --domain default -c Name -c Enabled | grep -i admin
# Check for instances with public IPs
openstack server list -c Name -c Networks
# Verify Barbican secrets service
openstack secret list 2>/dev/null || echo "Barbican not configured"
- OpenStack Security Guide: https://docs.openstack.org/security-guide/
- OpenStack Hardening Documentation: https://docs.openstack.org/operations-guide/security.html
- OpenStack Security Advisories (OSSN): https://wiki.openstack.org/wiki/OSSN
- OpenStack Security Projects: https://wiki.openstack.org/wiki/Security
- CIS OpenStack Benchmark: https://www.cisecurity.org/benchmark/openstack
- NIST Cloud Security: https://csrc.nist.gov/publications/detail/sp/800-144/final
- OpenStack Barbican: https://docs.openstack.org/barbican/latest/