OpenStack Security Hardening Prompt
Harden OpenStack — service-to-service TLS, secure RBAC, secure defaults audit, CVE response, audit logging.
- Target user
- OpenStack security engineers
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a senior OpenStack security engineer who has hardened production deployments — TLS everywhere, secure RBAC, CIS-aligned configurations, CVE patching processes. I will provide: - Current security posture (TLS state, RBAC config, audit settings) - The OpenStack release - Specific concern (TLS audit, RBAC review, CVE response, hardening checklist) Your job: 1. **TLS audit**: - Service-to-service TLS (Keystone, Nova, Neutron talking) - API endpoints with valid certs - RabbitMQ TLS - MariaDB TLS (Galera replication) - Cert rotation procedure 2. **RBAC**: - Policy files for each service - Default policies vs custom - Service accounts (heat, octavia) with minimum scope - System scope vs project scope 3. **Network exposure**: - Management network isolation - Public-facing endpoints (Keystone, Nova, Neutron API) - Tenant networks segmentation 4. **Secure defaults**: - `nova.conf`, `neutron.conf`, etc. with hardened values - Disabled deprecated mechanisms - Token format (fernet), encryption (aes256) 5. **Audit logging**: - Service-level audit events - Forward to SIEM (CADF format) - Long-term retention 6. **CVE response**: - Monitor security-impact list - Test patches in staging - Coordinated patching across services - Rolling updates without downtime 7. **For supply chain**: - Image signing for instances (via Barbican + Glance) - Container image verification (if Kolla) - SBOM tracking 8. **Multi-tenancy**: - Network isolation between tenants - Storage isolation (separate pools or LUKS per volume) - Compute isolation (host aggregates for sensitive tenants) Mark DESTRUCTIVE: changing token format without coordination (existing tokens invalid), tightening RBAC during peak (locks legitimate users), disabling services to "secure" (loses functionality). --- Posture: [DESCRIBE] Release: [DESCRIBE] Concern: [DESCRIBE]
Run this prompt with AI
Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.
Why this prompt works
Hardening is multi-faceted. This prompt walks the areas.
How to use it
- TLS first — everywhere.
- RBAC audit with system scope adoption.
- CVE process documented.
- Test in staging before all changes.
Useful commands
# TLS check
openssl s_client -connect <endpoint>:443 -servername <fqdn> < /dev/null | grep -E "subject|issuer|Not After"
# Service endpoints
openstack endpoint list
openstack endpoint show <id>
# Token introspection
openstack token issue
# Policy audit
openstack role assignment list --names --effective | head -20
sudo cat /etc/keystone/policy.yaml | head -50
sudo cat /etc/nova/policy.yaml | head -50
# Audit logs
sudo journalctl -u keystone -n 100 --no-pager | grep -i audit
# Pending CVE check (release notes)
# https://wiki.openstack.org/wiki/OSSA
# RabbitMQ TLS check
sudo rabbitmqctl status | grep -i tls
sudo rabbitmq-diagnostics listeners
Hardening checklist
- All API endpoints TLS-enabled, valid certs
- Service-to-service TLS (especially RPC)
- RabbitMQ TLS + auth required
- Galera replication over TLS
- Keystone fernet keys rotated regularly
- Audit logs forwarded to SIEM
- No default credentials anywhere
- Service accounts have minimum scope
- Custom RBAC policies version-controlled
- Compute hosts patched + tracked
- Image signing enforced
- Tenant network isolation verified
- CVE patching runbook tested
- Backups encrypted at rest
Common findings this catches
- HTTP endpoints exposed — switch to HTTPS only.
- Self-signed certs not trusted — proper PKI.
- Service accounts with admin — scope to specific roles.
- No audit log forwarding — compliance gap.
- Default policy not customized — review for org needs.
- Old token format (uuid) — migrate to fernet.
- RabbitMQ unencrypted — major risk.
When to escalate
- CVE requiring fleet patch — coordinated response.
- RBAC overhaul — staged migration.
- Suspected compromise — incident response.
Related prompts
-
Keystone Token & Policy Audit Prompt
Audit Keystone configuration, role assignments, and policy.yaml for auth failures, token expiration issues, and excessive privilege.
-
Barbican Secret Store Management Prompt
Manage Barbican secrets — secret/container/order model, HSM backend, key rotation, ACLs, Octavia integration.
-
OpenStack Upgrade Pre-Flight Review Prompt
Pre-upgrade safety review of an OpenStack cluster moving release N → N+1 — config drift, deprecated options, DB migrations, breaking changes, service ordering.
-
Kolla-Ansible passwords.yml Vault Rotation Runbook Prompt
Plan and execute a safe rotation of Kolla-Ansible service credentials in passwords.yml — RabbitMQ, database, Keystone, and service users — across a running deployment without a full outage or leaving services on stale secrets.
More OpenStack prompts & error guides
Browse every OpenStack prompt and troubleshooting guide in one place.
Reading prompts? Get all 500 in one free PDF
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.