Why OpenStack security hardening is harder than it looks
Hardening an OpenStack cloud is a set of configuration and operational decisions across the whole stack. No single setting makes a private cloud secure. If you are building or inheriting one, you are responsible for many API endpoints spread across compute, image, block storage, networking, orchestration and dashboard services, all trusting one shared identity service in Keystone, and for hypervisors that carry every tenant's workloads. Each of those surfaces needs its own decisions about TLS termination, authentication, network reachability, administrative access and logging, and those decisions interact. A control that looks sound in one service can be undone by a permissive setting in another.
Defaults are not a hardened baseline. A deployment that works on first boot has usually been configured for function, not for your threat model. Review the policy files each service reads, including Keystone policy, and check which roles your users and service accounts actually hold. Confirm which values your deployment tool sets and which it leaves at upstream defaults. For Kolla-Ansible or OpenStack-Ansible, read the configuration guide for your release and record each override in version control so you can show later what was changed and why. Treat the list of defaults you accept as a security decision with an owner, not as something you inherited silently.
The cloud is only as strong as its least-hardened service. An attacker does not need to go through Keystone if a neglected message queue, database, image service or hypervisor agent gives them a way in. Shared database and message queue credentials mean that one weak service can expose several others. Before you start, build an inventory that lists each service, its exposed endpoints, the credentials it holds, where those credentials are stored and who can read them. Then decide the hardening standard for each service and test it, rather than assuming the platform team's strongest component sets the level for everything else.
Hardening must be tied to a maintained release branch, or you cannot apply the patches that matter. Stable branches are maintained for approximately 18 months. After that, only SLURP releases may move to an unmaintained phase with no releases and reduced CI, before end of life. A cloud on an out-of-maintenance branch has no normal path to security fixes. Check the current status of your chosen release on the OpenStack releases site before you commit. At the time of writing, 2025.1 Epoxy and 2025.2 Flamingo were in the maintained phase, and 2026.1 Gazpacho is a SLURP release. Confirm these statuses yourself, because they change.
This work applies to any self-hosted OpenStack deployment in your own infrastructure, whether in your data centers, your cloud accounts or an isolated network. OpenStack is open source under the Apache License, Version 2.0, and the project does not publish a vendor-supplied hardened image. If you use a commercial distribution or a managed partner, ask in writing what hardening it applies, which settings it leaves to you, how it delivers security patches and how quickly. Those answers determine how much of the work in this guide is already done and how much your team must own.
Components and settings that carry the security boundary
An OpenStack cloud is only as isolated as its weakest control plane service, and each component below carries a different part of that boundary. Review them together, because a gap in identity, networking or the shared backing services can expose tenants that look correctly separated in every other respect.
Public and internal API endpoints
Each OpenStack service exposes an API, and the public, internal and admin endpoints in the service catalog are separate exposures that need separate controls. Check that every endpoint is served over TLS with certificates your team issues and rotates, that internal and admin endpoints cannot be reached from tenant networks or the internet, and that the catalog lists only the endpoints you intend to publish. Confirm TLS and endpoint settings for your release in its documentation, since defaults differ between deployment tools.
Keystone and policy files
Keystone issues the tokens that every other service trusts, so its configuration and federation trust form the root of the boundary. Check token lifetimes, the identity backends in use, the trusted identity providers, and the mapping rules that turn federated users into roles and projects. Each service's policy file decides which role may perform which action, so keep those files under version control, review every change, and test them in a non-production cloud before rollout.
Neutron tenant network isolation
Neutron builds the virtual networks, routers, ports and security groups that separate tenants on shared hardware. Verify that tenant networks stay segregated at the overlay layer, that provider networks have no route into management subnets, and that security group rules deny inbound traffic unless a project explicitly allows it. Policy gaps can let a tenant create ports or attach to networks it does not own, so test isolation with traffic checks between projects and do not rely on configuration review alone.
Nova and hypervisor hosts
Nova schedules guests onto compute hosts, and each hypervisor runs tenant workloads on a shared kernel. Check that host operating systems are patched within a maintained OpenStack and vendor branch, that SSH and console access to hypervisors is restricted to named administrators, and that management traffic is separated from guest traffic. Review the Nova settings for live migration and console access, and confirm host-level hardening steps against your release documentation and your host OS vendor guidance.
Glance, Cinder and secret stores
Images, volumes, backups and any stored secrets hold tenant data at rest. Check that images come from trusted sources and are verified before use where your workflow supports it, that volume and backup encryption are enabled where your release and storage backend support them, and that Ceph pools backing these services are access-controlled per service. If Barbican or another secret store is deployed, confirm which services read from it, who can retrieve secrets, and how keys are rotated and recovered.
Message queue, database and tooling
The message queue and database carry credentials and state for every service, and the deployment tooling writes the configuration that sets all of it. Check that queue and database connections use TLS with per-service credentials, that database access is limited to control plane hosts, and that secrets in inventories and templates are encrypted or kept out of version control. Pin tool versions, review configuration changes, and record who approved each change in the deployment repository.
Decisions to settle before hardening starts
This table compares the six decisions that shape an OpenStack hardening programme, with the options for each, when they fit and what they cost to run day to day. Read each row as a question to answer before configuration begins, since later choices depend on the earlier ones. The main takeaway is that identity, secrets and the deployment tool determine how much of the hardening can be repeated and patched without manual drift.
| Decision | Option and when it fits | Operational consequence |
|---|---|---|
| Internal API TLS trust | Private certificate authority fits when all Keystone, Nova, Neutron, Glance and Cinder endpoints stay inside the client's own network and the team can run CA rotation. A managed CA fits when the security team already operates one and wants central issuance and revocation. | A private CA means the team owns root key protection, certificate renewal for every endpoint and client trust bundles on each host. A managed CA shifts issuance to another team but still needs endpoint configuration, renewal automation and a tested process for certificate expiry. |
| Identity source | Keystone federation to an external identity provider over SAML 2.0 or OpenID Connect fits organizations with a central directory and joiner-mover-leaver processes. Local users fit small or air-gapped estates with few administrators. | Federation requires mapping rules that tie identity provider groups to projects and roles, and those rules need review whenever groups change. Local users are simpler to start with but leave account removal and password policy to the cloud team. |
| Tenant network segmentation | Provider networks fit flat or VLAN-based estates with strong upstream firewalling. Per-tenant overlays fit multi-tenant clouds where tenants must not reach each other by default. A mix fits clouds with a few shared services networks and many isolated project networks. | Overlays add tunnelling overhead and make network troubleshooting depend on the overlay layer. Provider networks move enforcement to physical or upstream devices, so changes need coordination with the network team. |
| Secrets storage | Configuration management vault fits teams already using Ansible Vault or a similar tool for deployment inventories. A dedicated secrets service fits larger estates needing audited access, dynamic credentials or rotation at scale. Encrypted files fit only small, short-lived setups. | A vault adds a key or password to manage and a dependency for every deployment run. A dedicated service adds its own hardening, backup and high availability work. Encrypted files depend on disciplined key handling and are hard to audit. |
| Hypervisor lockdown | Host-based access controls fit estates where compute nodes are managed as long-lived servers. Kernel and firmware baselines fit regulated estates that must show configuration evidence for each host. A managed host image fits large fleets where nodes are rebuilt rather than patched in place. | Host-based controls need ongoing access review and jump host management. Baselines require scanning, exception tracking and firmware update planning. Managed images need an image pipeline and a rebuild procedure that works with live migration and maintenance windows. |
| Deployment tool and patch branch | Kolla-Ansible (containers) and OpenStack-Ansible (LXC containers or bare metal) are the two deployment tools covered by the 2026.1 guides, and the choice should match the team's container skills. Patches should follow a maintained release, with SLURP releases preferred for longer support windows. | The chosen tool determines how hardening settings are templated and how patches are applied. Stable branches are maintained for approximately 18 months, so the team must schedule upgrades to stay on a maintained release. Confirm the exact support dates for the chosen release on the OpenStack releases site. |
How to build the hardened baseline, step by step
This sequence moves an OpenStack cloud from an unverified state to a documented baseline. Each step closes with a check that produces evidence you can keep, compare and repeat after upgrades.
Inventory endpoints, service accounts and releases
The operator lists every API endpoint in the service catalog, every internal service endpoint, the message queue and database connections, and each service account with the roles it holds. The team also records the release each service runs, confirmed on the hosts or containers themselves. The step is complete when the list reconciles with the catalog output and the running software on each host. Any endpoint or account missing from the list is investigated before step two begins.
Enable TLS on every API endpoint
The operator configures TLS on each public and internal API endpoint, including the identity service, and removes plaintext listeners on those ports. Certificates are issued from the organization's chosen certificate authority, and the team checks that each chain completes to a trusted root and that the subject or subject alternative names match the endpoint names clients use. The check is a scan of every endpoint showing a complete chain, a matching hostname and no plaintext listener. Store the scan output with the baseline record.
Harden Keystone tokens, sessions and policies
The operator sets token and session lifetimes in the identity service to match the organization's security policy and enforces multi-factor authentication at the federated identity provider where Keystone federation is used. The team then reviews the policy files for each service against upstream defaults and records every change with its reason. The check is a policy diff reviewed by a second engineer, plus a test login showing that an account without the required factor is refused. Keep the diff in version control.
Define and test tenant network isolation
The team designs tenant networks, security group defaults and the separation of provider, tenant and management networks, then implements them through the deployment tool. The management network must not be reachable from any tenant network. The test creates instances in at least two projects and attempts connections between them and to management addresses, expecting every attempt to fail. Record the failed connection results as evidence. Repeat the test whenever network configuration changes.
Move secrets out of plain configuration
The operator moves database passwords, service account credentials and API keys out of plain configuration files and version control and into a managed secret store or an encrypted deployment mechanism. The team documents who can read each secret and how each one is rotated. The check is a search of configuration files, repositories and container images that finds no plaintext credentials, followed by a rotation test on one service account that confirms the services reconnect with the new value. Record the rotation procedure in the baseline.
Apply hypervisor and host access controls
The operator hardens the compute, network and storage hosts against a host configuration benchmark for the operating system in use, disables direct root login over SSH, limits administrative access to named accounts and applies host firewall rules that match the network design. Changes are made through configuration management so they can be repeated. The check is a host scan against the agreed benchmark, with any accepted deviations documented and signed off. The scan output becomes part of the baseline.
Set a patch path and record the baseline
The team defines how security updates are tested in staging and promoted to production within the release branch the cloud runs. OpenStack stable branches are maintained for about 18 months, so the patch path must follow the branch the cloud is on and the upgrade plan for moving to a newer one. The team then records the baseline: release versions, endpoint scan results, the Keystone policy diff, the isolation test results and the rotation record. The step closes when a named owner approves the document.
How to test the hardened cloud and confirm it fails safely
Testing a hardened OpenStack cloud has two goals: confirm the baseline controls behave as designed, and confirm that when something breaks, the cloud fails closed rather than exposing tenant data or identities. Start by scanning every API endpoint from both sides of the trust boundary. An external TLS scan of the public Keystone, Nova, Neutron, Glance, Cinder and Horizon endpoints should confirm supported protocol versions, cipher suites, certificate chain validity and hostname matching. An internal scan from the management network should cover the same services plus database, message queue and memcached listeners, which should not be reachable from tenant or public segments at all. Record each finding against the endpoint, the date and the tool version so the scan can be repeated after every change.
The authorization test matrix is the most useful verification artifact you will produce. Build a table with one row per API operation you care about (for example, creating a server, attaching a volume, listing networks, changing a quota) and one column per combination of role and project: an administrator in the admin project, a member in project A, a reader in project A, a member in project B, and an unscoped federated user with no role mapping. Call each operation as each identity with the CLI or API, and record allowed or denied for each cell alongside the expected result from your Keystone policy design. Any mismatch is a finding. Keep the matrix under version control with the policy files it tests, so a policy change forces a matrix update. Confirm with your Keystone and policy owners which operations are intentionally admin-only before you write expected results.
Cross-tenant network reachability needs direct testing, not assumption. From an instance in project A, attempt to reach instances, floating IPs, router interfaces and metadata services belonging to project B, using the same tenant network CIDRs where your design permits overlap. Test security group rules as configured, then test with the rules deliberately relaxed in a staging project to prove the isolation does not depend on a single control. Review secrets exposure at the same time: search Nova, Glance and Heat templates, hypervisor-side configuration, deployment inventories and service logs for database passwords, service account credentials, API tokens and private keys. Confirm that debug logging is off in production and that logs redact credentials. Your deployment tool's secrets store should be the only place these values live, and you should be able to say which team can read it.
Failure-mode tests show whether the controls hold under stress. Revoke a federated user at the identity provider, then confirm that the user's Keystone token issuance fails and that an existing token is rejected once it expires or is revoked, with the revocation time recorded. Expire a certificate on a staging endpoint and confirm that your monitoring raises the alert at the threshold you set and that the alert reaches the on-call channel. Stop a compute host in a staging region and confirm that its instances are not reachable through floating IPs or the provider network, that no tenant network is bridged to a management interface during the outage, and that evacuation or recovery behaves as your runbook states. Each test should name the expected result before it runs. Ask your implementation partner to show the timing and the exact commands used, so the test can be repeated during an assessment.
Keep every result as evidence: scan reports, the completed authorization matrix, reachability test logs, secrets review notes, alert screenshots or log extracts, and dated runbook records of each failure test. Store them with the configuration version they describe. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make that determination, and they will ask who performed each test, when it ran and whether the results were reviewed. Confirm with your assessor, before testing begins, which control frameworks apply and what format of evidence they accept. Plan to repeat the full set after each OpenStack upgrade, because policy defaults and service behavior change between releases.
What drives the effort and how to keep it down
This table lists the factors that most change the scope of an OpenStack security hardening engagement, what makes each one larger and how to narrow it. Read each row against your own environment, then use the list to shape a written scope before asking for a quote.
| Driver | What makes it larger | How to reduce it |
|---|---|---|
| Services and API endpoints enabled | Many enabled services, each with its own API endpoint, TLS configuration, service account and policy file to review and test | Enable only services you need in the first phase, and document the endpoints in scope so each one is hardened and tested once |
| Tenants, projects and roles | Many projects with custom roles, nested access and exceptions to default policy each need mapping, testing and evidence | Standardize on a small role model, reuse it across projects and record exceptions with an owner and review date |
| Federation and external identity sources | SAML 2.0 or OpenID Connect federation, LDAP backends and Keystone-to-Keystone links each add trust settings, mapping rules and failure cases to verify | Limit the first phase to one identity provider and one mapping set, and defer secondary sources to a later change |
| Hypervisor hosts and hardware diversity | More hosts and mixed hardware generations mean more kernel, firmware and driver baselines to build, patch and check | Use a single host image and a small number of hardware profiles, and agree how many hosts are sampled for verification |
| Network design complexity | Overlay networks, provider networks, VLAN segmentation and security group rules multiply the isolation tests needed for tenant separation | Keep one documented network model, document each provider network with its purpose, and test isolation for the models you actually run |
| Number of environments | Each environment such as staging, pre-production and production repeats configuration, testing and evidence collection | Build one automated deployment pipeline with environment-specific variables, and test hardening changes in staging before production |
| Customization of policies or dashboard | Custom Keystone or service policy files and Horizon changes must be reviewed against each upstream release and retested after upgrades | Keep changes minimal and well documented, and confirm which custom files will need review during each upgrade |
| Compliance scope and control frameworks | Each framework adds its own control mapping, evidence format and assessor questions, and the same control may need several pieces of evidence | Agree the framework list and the control set before work starts, and ask the auditor which evidence format they accept |
Access control and secrets handling specific to OpenStack
Most OpenStack compromises start with an over-privileged identity, a leaked credential or an administrator path nobody reviews. The five controls below cover who can act in the cloud, how service credentials stay current, where secrets may live, how administrators reach the control plane, and how the hypervisors and hosts underneath are kept lean.
Least-privilege Keystone roles and policy review
Keystone scopes every token to a project and a set of roles, so the first question is whether each user, group and automation account holds only the roles its job requires. Review the policy files for each service, including Nova, Neutron, Cinder, Glance and Placement, to confirm which roles can perform administrative actions. Default policies differ between releases, so compare your overrides against the policy defaults of the release you run and record every deviation with a reason.
Service account credentials and rotation
Each OpenStack service authenticates to Keystone with its own account, and those credentials sit in service configuration files on the control plane. Give each service a dedicated account with the minimum role, store its password outside shared files, and define a rotation procedure that updates Keystone and every consuming service in one controlled change. Ask your deployment team how a rotation is tested in a staging environment before production, and who approves it.
Secrets in configuration management
Deployment tooling such as Kolla-Ansible or OpenStack-Ansible renders passwords into service configuration, so the inventory and variable files are where secrets most often leak. Keep secrets in encrypted variables, in lookups against a vault service, or in an external secret store, and enforce the rule that secrets never appear in version-controlled plain text. Check the repository history as well as the current tree, because a secret committed once remains exposed until it is rotated.
Administrative access paths and API audit logging
Administrators should reach the control plane through a bastion or jump host with individual accounts and session recording, not by logging in directly to controllers or using shared root access. Enable audit logging for administrative API calls across Keystone and the core services, and forward those logs to a store that the cloud administrators cannot edit. Test the path by confirming that a single administrative action appears in the audit trail with the acting identity attached.
Hypervisor and host hardening baseline
Compute nodes and controllers run the cloud's privileged code, so each host should carry only the packages its role needs, accept SSH only from approved networks and keys, and follow a kernel configuration baseline. Use a recognized benchmark such as the CIS Benchmarks for your operating system as the starting checklist, then document each deviation that the hypervisor or storage client needs. Re-run the checks after every patch cycle, since package updates can reintroduce settings the baseline removed.
How hardening changes by deployment model
A single-node lab runs the control plane, compute and storage on one host. It is useful for testing Keystone policies and API TLS settings, but it does not show how production exposure, trust distribution or patch timing will behave. Teams often take shortcuts here, and those shortcuts tend to carry forward into later builds.
- Certificates: Self-signed or private CA certificates are often created by hand and placed directly in the configuration. Confirm the lab exercises the same TLS settings planned for production.
- Secrets: Passwords may sit in a local file. Keep that file out of shared repositories and regenerate every secret before any production data is loaded.
- Patch delivery: Updates are commonly applied directly from an upstream package mirror. Record the exact release and package versions so the lab matches what production will use.
- Evidence: Keep a short log of configuration changes and test results so the same checks can run against the production build.
Check that nothing from the lab, including the test certificate authority and generated passwords, moves into production without being regenerated.
A highly available production cloud runs API services on several controller nodes behind a load balancer, with a clustered database and message queue. Every endpoint, certificate and secret must stay consistent across nodes, so hardening decisions multiply with the node count.
- Certificates: Issue endpoint certificates whose names match the virtual IP and load balancer addresses. Distribute the CA chain to every controller, compute host and client that connects to them.
- Secrets: Store service, database and message queue credentials in an encrypted store with a rotation procedure that reaches all nodes in the same change.
- Patch delivery: Roll updates one node at a time so the cluster keeps serving requests. Confirm the upgrade order for database and queue components in the release notes for the branch in use.
- Evidence: Record which node runs which package version and which certificate serial it presents, so audit samples can be traced across the cluster.
Confirm that a failed controller can be replaced without reissuing the whole CA or reusing a shared service secret across environments.
The 2026.1 deployment guides cover Kolla-Ansible, which deploys OpenStack services in Docker containers driven by Ansible. Configuration is templated from global settings and per-service overrides, so hardening settings are applied through templates and inventory. Patches arrive as new container images that the playbooks deploy.
- Certificates: Place TLS certificates in the paths the templates read. Keep the CA bundle in the controlled deployment repository so every container uses the same trust store.
- Secrets: Kolla-Ansible generates service passwords into a passwords file. Encrypt that file with a vault mechanism and limit who can read the repository.
- Patch delivery: Pin image tags, pull or build updated images, and rerun the playbooks. Confirm the source registry and tags before each run.
- Evidence: Commit the globals file, inventory and overrides to version control so each change has an author, a diff and a reviewable history.
Check that the image tags, template overrides and encrypted passwords file in the repository match what is running on the hosts.
The 2026.1 deployment guides also cover OpenStack-Ansible, which deploys services in LXC containers or directly on bare metal using Ansible roles and user configuration files. The hardening surface includes host packages as well as service containers, so patching touches the host operating system and the OpenStack components together.
- Certificates: Set certificate paths in the user configuration files. Confirm which hosts receive the CA bundle, including bare-metal compute and storage hosts that run no containers.
- Secrets: Use the generated user secrets file, encrypted with Ansible Vault. Keep host access separate from the access needed to run playbooks.
- Patch delivery: Operating system updates reach hosts through the distribution mirror, while OpenStack updates come from the branch playbooks. Test both together on a staging copy because they can touch the same packages.
- Evidence: Keep user configuration files, pinned role versions and host inventories under version control, and record which playbook run applied which change.
Confirm the host patch cadence and the OpenStack release branch are planned together so that neither update surprises the other.
On air-gapped networks, hosts cannot reach public registries or package repositories. Container images, Python packages, operating system packages and Ansible roles must be mirrored into an internal location before deployment. Patch intake then becomes a controlled process with review, scanning and approval before anything reaches production.
- Certificates: Use an internal CA and distribute its root to every host and client through the internal configuration path. Plan renewal well before the CA or leaf certificates expire, because no public service can reissue them.
- Secrets: Generate secrets inside the enclave and never import them from outside. Store vault keys separately from the encrypted files they open.
- Patch delivery: Mirror only approved releases, scan artifacts on import, and record an approval before the internal mirror is updated.
- Evidence: Log every import with its source, checksum, date and approver, so each deployed image or package can be traced to an approved intake record.
Confirm that every image and package the deployment needs is in the internal mirror, and that an intake record exists for each, before the change window opens.
What to monitor, back up, patch and document after go-live
Hardening decays quickly after go-live unless someone watches the signals that show the controls still work. Start with five checks. Track expiry dates for every API endpoint certificate and for the internal certificates between control plane services, with alerts well before expiry so renewals never happen during an incident. Review failed authentication events in Keystone logs, grouped by source address and user, to spot password guessing and misconfigured federated logins. Watch policy denials from the services that enforce Keystone policies, because a sudden rise often means a policy file changed or an integration is calling an API it was never granted. Feed administrative API calls, especially role assignments, project changes and quota edits, into a central log store with retention set by your audit requirements. Finally, compare the configuration on each host with the approved baseline on a schedule, so drift is found by a job rather than by an auditor.
Backups for OpenStack security depend on two stores that are hard to rebuild: the Keystone database, which holds identities, role assignments and federation mappings, and the secrets store that holds service passwords, database credentials and the keys used for encryption. Back up both on a schedule, encrypt every backup at rest with keys held separately from the backup media, and restrict access to the backup system to a small named group. A backup that has never been restored is an assumption, so run restore tests into an isolated environment on a fixed cadence. Each test should prove that a user can authenticate, that a service can read its secret, and that the restored Keystone database matches the expected role assignments. Record what was restored, by whom and how long it took, and treat a failed test as an incident.
Patching should follow the security advisories for the release you actually run, not the newest release available. Subscribe to the OpenStack security mailing list and to advisories for the components in your deployment, including the hypervisor, the database and the message queue, because OpenStack advisories do not cover those. OpenStack stable branches are maintained for approximately 18 months, and after that only SLURP releases may enter an unmaintained phase, so the release status decides how much time you have. At the time of writing, 2025.1 Epoxy and 2025.2 Flamingo are in the maintained phase and 2026.1 Gazpacho is a SLURP release. Confirm the current status of each branch on the OpenStack releases site before you plan any patch window. Moving to a newer release is a separate project, covered in the OpenStack upgrades and support topic.
The hardening baseline is only useful if it can be reproduced and audited, so keep it in version control with everything that defines the cloud. That includes the TLS settings for API endpoints, Keystone policy files, service configuration, network isolation rules, host hardening profiles and the deployment inventory used by Kolla-Ansible or OpenStack-Ansible. Every change should go through a commit that names the reason, the reviewer and the change record, and production should deploy only from tagged revisions. Keep a short runbook for each control that states its purpose, its owner and the check that proves it still holds. When a control changes, update the runbook in the same commit, so the evidence you give an assessor matches what is running.
Questions teams ask before hardening OpenStack
What does OpenStack security hardening cost, and what drives the price?
The cost follows from the written scope, which is agreed in writing before work starts. The one-time portion usually covers discovery of the current configuration, changes to API endpoint TLS, Keystone policy, tenant network isolation, secrets handling and hypervisor settings, testing, and handover documentation. Recurring costs cover patch cycles, periodic reviews and any retainer for ongoing support. The main drivers are the number of services and nodes in scope, the deployment tooling already in place, the number of tenants and networks, the condition of the existing configuration, and how much test evidence you need. DeployOpen does not publish a price list. When you request a quote, ask it to separate one-time and recurring items, name each service in scope, list what your team provides, and state the assumptions about change windows and environments.
How long does an OpenStack hardening engagement take?
The timeline is set by the scope, dependencies on your team and the environment you are working in, so ask for it in the written scope rather than relying on a general estimate. The biggest drivers are the number of control plane and compute nodes, whether a staging environment matches production, how often change windows are available, your internal approval cycles, and whether the cloud is already serving production tenants. Most engagements are fixed-scope, so the agreed deliverables and timelines should name milestones, the client decisions each milestone depends on, and what you receive at each stage. If a proposal does not show those dependencies, ask for them before you compare timelines across vendors.
Can our own team harden OpenStack without outside help?
A capable internal team can do much of the work, provided the people involved already run OpenStack in production. The skills that matter include operating OpenStack services through your deployment tool, which is typically Kolla-Ansible or OpenStack-Ansible, along with Keystone policy, TLS certificate management, network design, secrets management, hypervisor administration and tracking of upstream security fixes. Your team also needs a staging environment to test changes and enough time to work through them alongside daily operations. Many organizations bring in an outside team for a fixed hardening pass and knowledge transfer, then keep the controls in-house. Check whether named staff can own each control area after handover.
What does the hardening work need from our organization?
Hardening needs access, decisions and a safe place to test. Provide access to the environment, whether that is cloud accounts, data center systems or an air-gapped network. Name an owner for identity, networking, storage, compute and security, and make sure those owners can approve changes. Schedule change windows that match your operational rules. Provide a test environment that is close enough to production to catch problems, along with current deployment inventories and configuration files, ideally already kept under version control. Document any exceptions your organization has already approved, because those decisions affect what can be changed. Ask the quote to list each dependency so gaps show up before work starts.
Can OpenStack be hardened while the cloud is running production workloads?
Yes, in most cases, but changes must be staged so tenants are not affected without warning. Changes to API endpoints, Keystone policy, network isolation or hypervisor settings can interrupt services or break tenant workflows, so they should be tested in staging first and then applied in agreed windows. Where your control plane is redundant, changes can usually roll across nodes one at a time. Confirm with your deployment tooling how configuration changes are applied and whether a service restart is required. Some hardening steps, especially those touching the hypervisor, may need a maintenance window that the written scope should name.
Does OpenStack hardening replace a security audit or certification?
No. Hardening changes the configuration of the cloud, while an audit independently tests whether controls are designed, operated and evidenced against a defined scope. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. Before you start, ask whether evidence collection is part of the agreed scope, which evidence your auditor expects, and who maintains that evidence after the engagement. Separate security testing of the platform can also be scoped if you need an independent view of the hardened configuration.
How does patching work within maintained OpenStack branches?
Patching depends on staying on a branch that is still maintained. OpenStack stable branches are maintained for approximately 18 months. After that, only SLURP releases may move into an unmaintained phase with no releases and reduced CI, before end of life. The 2026.1 Gazpacho release is a SLURP release, and 2025.1 Epoxy and 2025.2 Flamingo are listed as maintained. Confirm the current status of any branch on the OpenStack releases site, because the status changes over time. Patches are applied through your deployment tooling, and each hardening control should be retested after patching or upgrading. Plan upgrades before a branch leaves maintenance so security fixes do not stop arriving.
How DeployOpen scopes, hardens and hands over OpenStack security work
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including OpenStack. For security hardening, we agree a written scope first, apply controls to the OpenStack release branch you actually run, and leave you with the configuration, tests and runbooks to keep it hardened.
How we scope
- Inventory every API endpoint, Keystone policy, tenant network and hypervisor in the written scope before any change is made.
- Confirm which OpenStack release and deployment tool you run, since maintained branches determine which hardening settings apply.
- Agree in writing which controls, environments and services are covered, because engagements are fixed-scope with deliverables and timelines set in advance.
How we build
- Apply TLS to API endpoints and internal service traffic using certificates and key handling that your own certificate authority can manage.
- Tighten Keystone policies and tenant network isolation, then test that each project can reach only the resources it is granted.
- Move secrets out of plain configuration, harden hypervisor settings and verify patches land on the maintained branch you run.
How we hand over
- Deliver the hardened configuration under version control, so each change can be reviewed, reproduced and rolled back.
- Document the security baseline, the test results and the evidence each control produces, ready for your internal review or an external assessor.
- Walk your operations team through patching, policy changes and the runbooks they will use after the engagement closes.
How we support
- Ongoing support, upgrades and continuous security testing are available as a retainer, sized to the scope you agree.
- Retainers can cover patch review against maintained OpenStack branches, including planning for SLURP-aligned upgrades when your release window arrives.
- Confirm the support level, response expectations and included services in writing with your DeployOpen quote before work starts.
