Network Security
Internet Exposure and Risk
Compute instances can connect to public networks. If security groups allow unrestricted inbound traffic, services running on those instances can become publicly accessible.
Exposing services to the internet can lead to:
- Unauthorized access
- Automated scanning and exploitation attempts
- Data breaches or data loss
- Abuse of compute resources
Reduce your exposure by applying the methods described below to limit the attack surface on your systems.
Security Groups
Security groups act as stateful virtual firewalls for compute instances. They control which inbound and outbound network traffic your instances accept.
Without explicit configuration, security groups enforce a restrictive default policy: all outbound traffic passes through, all inbound traffic gets blocked, and traffic from private networks within the same project flows freely. Review and adjust security group rules to match your security requirements.
For details, please visit Security Groups.
Recommendations
- Apply the principle of least privilege
- Deny all inbound traffic by default
- Permit required ports and protocols
- Restrict access by source IP wherever possible
- Periodically review and audit security group rules
Example: Recommended Restrictive Configuration
Use case: A compute instance running a web application with administrative access via SSH.
Inbound Rules
| Protocol | Port | Source | Description |
|---|---|---|---|
| TCP | 22 | 203.0.113.10/32 |
SSH administration |
| TCP | 80 | 0.0.0.0/0 |
HTTP |
| TCP | 443 | 0.0.0.0/0 |
HTTPS |
All other inbound traffic should be denied.
Outbound Rules
Outbound traffic often passes by default. Restrict outbound access if your workload does not require it.
Example: Database Server (Internal Access Only)
Use case: A database instance (for example, MySQL or PostgreSQL) that requires access from the internal application network rather than the public internet.
Inbound Rules
| Protocol | Port | Source | Description |
|---|---|---|---|
| TCP | 3306 | 10.0.1.0/24 |
MySQL access from application subnet |
| TCP | 5432 | 10.0.1.0/24 |
PostgreSQL access from application subnet |
All other inbound traffic should be denied.
Outbound Rules
| Protocol | Port | Destination | Description |
|---|---|---|---|
| TCP | 443 | 0.0.0.0/0 |
Database updates / external services |
| UDP | 53 | 10.0.0.2 |
Internal DNS |
Restrict outbound traffic to the paths you need for updates, backups, and monitoring.
Example: Application Server (Multi-Tier Architecture)
Use case: An application server receiving traffic from a public load balancer and connecting to an internal database.
Inbound Rules
| Protocol | Port | Source | Description |
|---|---|---|---|
| TCP | 8080 | 10.0.0.0/24 |
Traffic from load balancer subnet |
| TCP | 22 | 203.0.113.10/32 |
SSH administration |
All other inbound traffic should be denied.
Outbound Rules
| Protocol | Port | Destination | Description |
|---|---|---|---|
| TCP | 3306 | 10.0.2.0/24 |
Database access |
| TCP | 443 | 0.0.0.0/0 |
External APIs |
| UDP | 53 | 10.0.0.2 |
Internal DNS |
Example: Bastion Host (Jump Host)
Use case: A bastion host providing controlled administrative access to internal systems.
Inbound Rules
| Protocol | Port | Source | Description |
|---|---|---|---|
| TCP | 22 | 203.0.113.10/32 |
SSH from trusted admin IPs |
All other inbound traffic should be denied.
Outbound Rules
| Protocol | Port | Destination | Description |
|---|---|---|---|
| TCP | 22 | 10.0.0.0/16 |
SSH to internal instances |
| TCP | 443 | 0.0.0.0/0 |
OS updates |
Example: Internal-Only Service (No Internet Access)
Use case: A compute instance running an internal microservice that should never communicate with external networks.
Inbound Rules
| Protocol | Port | Source | Description |
|---|---|---|---|
| TCP | 9000 | 10.0.0.0/16 |
Internal service traffic |
All other inbound traffic should be denied.
Outbound Rules
| Protocol | Port | Destination | Description |
|---|---|---|---|
| TCP | 9000 | 10.0.0.0/16 |
Internal service communication |
| UDP | 53 | 10.0.0.2 |
Internal DNS |
All internet-bound outbound traffic should be denied.
Firewall as a Service (FWaaS)
Firewall as a Service (FWaaS) in OpenStack provides centralized, policy-based network firewalling at the network or router level. It allows you to define firewall rules that control traffic between networks, subnets, and external networks, rather than on individual compute instances.
FWaaS enforces consistent security policies across customer workloads and segments network traffic effectively.
For details, please visit FWaaS.
Security Groups vs. FWaaS
While both Security Groups and FWaaS control network traffic, they operate at different layers and serve different purposes.
| Feature | Security Groups | FWaaS |
|---|---|---|
| Scope | Individual compute instances (ports) | Networks / routers |
| Firewall type | Distributed, instance-level | Centralized, network-level |
| Stateful | Yes | Yes |
| Typical use case | Protecting single instances | Network segmentation and policy enforcement |
| Granularity | Per instance / per port | Per network or router |
| Management | Applied directly to instances | Applied centrally |
| Best suited for | Workload-level access control | Enterprise-grade network security |
When to Use Which
Use Security Groups when:
- You need fine-grained control per compute instance
- You want lightweight, instance-level protection
- You manage access to specific ports and protocols
Use FWaaS when:
- You require centralized firewall policies
- You need to control traffic between networks or subnets
- You want consistent enforcement across customer workloads
- You need network segmentation or perimeter firewalling
Best Practice
Security Groups and FWaaS complement each other. Combine them to create a defense-in-depth security model:
- Security Groups provide first-line, instance-level protection
- FWaaS enforces network-wide security policies and segmentation
Common Misconfigurations
The following configurations pose a real security risk:
- Allowing SSH (
22) access from0.0.0.0/0 - Exposing databases or internal services to the public internet
- Allowing wide port ranges without a clear business need
- Assuming we monitor or blocks insecure customer configurations