How do you prevent OpenStack compute instances from being exposed to the internet?

Keep OpenStack instances on private networking by default

The cleanest prevention is architectural: launch compute instances on private subnets or tenant networks that have no direct internet route, then expose only the specific services that actually need it through a controlled edge pattern. In practice, that means treating public reachability as an exception, not the default, and reviewing whether a workload needs internet access at all before a public IP is assigned.

Cloud Network Security Guide is the right starting point when you need a practical model for private network design, security group boundaries, and egress control across cloud workloads.

Imperva breach 2019 is a useful reminder that an exposed compute instance can become the path to stolen credentials and broader data access, even when the instance itself is not the ultimate target.

Control public exposure through IP, routing, and security policy

OpenStack exposure is rarely just a firewall question. Public IP assignment, floating IP binding, router configuration, security group ingress, and host or perimeter firewall policy all have to agree for an instance to stay off the public internet. If any one of those controls is too permissive, a workload that was meant to stay private can become reachable from outside the tenant boundary.

The most common failure mode is accidental exposure through floating IPs, overly broad ingress rules, or an image and instance pattern that places admin services on a reachable interface. Management ports, metadata services, and application listeners should not be left open just because the instance sits in an internal subnet. The control objective is to make public reachability explicit, narrow, and reviewable.

The State of NHI & AI Agent Breach Report 2026 provides broader incident context on what attackers do after they find exposed access paths, including credential theft and lateral movement.

OWASP API Security Top 10 is relevant when exposed instances host APIs, because broken authentication and authorisation at the service layer often turn network exposure into compromise.

Design for allowed exceptions, not accidental internet reachability

Some instances do need controlled exposure, but the pattern should be deliberate: place a load balancer, bastion, reverse proxy, VPN, or zero trust access layer in front of the workload rather than giving the instance an open public path. That lets you publish only the required service, preserve private addressing for the server itself, and centralise logging, rate limiting, and access checks.

When a public endpoint is unavoidable, the exposure should be limited to the minimum ports, minimum source ranges, and minimum duration needed. Revisit whether the instance still requires the same public route after deployment, because temporary access often becomes permanent if it is never reviewed. NIST Cybersecurity Framework 2.0 is a good operational reference for making that review repeatable across environments.

Risk and Threat Considerations

Internet exposure increases the chance that scanning, brute-force attempts, service misconfiguration, or leaked credentials will turn a routine instance into an attacker entry point. The risk is highest when a public IP is attached to a workload that was never meant to be customer-facing, or when management interfaces are reachable from broad source ranges.

Failure mechanism: A public route, weak ingress rule, or misbound floating IP creates an externally reachable attack surface that attackers can discover without prior access.

Impact: The instance may be probed, authenticated to, or abused for credential theft, data access, or lateral movement into adjacent cloud resources.

Practitioner Guidance

What to verify: Confirm that each instance has an explicit exposure decision, no unintended floating IPs, and no security group rule that allows broad inbound access to administrative or application ports.

Decision rule: If the instance does not have a clear business need for direct internet reachability, keep it private and publish access through a controlled front end instead of attaching a public IP.

Common mistake: Teams often check the initial network design but skip the follow-up review after resizing, redeploying, or reassigning a floating IP, which is when accidental exposure usually appears.

Practitioner takeaway: Treat public exposure as an approved exception with an owner and review point, because the real failure is usually not the absence of a firewall rule, but the drift between intended and actual routing.

Related resources from NHI Mgmt Group

• How should teams reduce the risk from exposed NHI secrets?
• How should security teams prevent exposed internet-facing systems from becoming the first step in an identity-based ransomware attack?
• How should security teams prevent databases from being exposed directly to the internet?
• Why do exposed internet-facing GitLab instances create such high risk for attackers?