Network Security
Network Security
Internet Exposure and Risk
Compute instances may be connected 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
You will need to limit the exposure of your workloads by e.g. using the methods described below to limit the attack surface to your systems.
Security Groups
Security groups act as stateful virtual firewalls for compute instances. They define which inbound and outbound network traffic is allowed.
Default configurations may allow more access than required for secure or production-grade workloads. If not configured differently security group contain a default rule that allows outgoing traffic and denies incoming traffic and traffic from your private networks in the same project is allowed. You must review and adjust security group rules according to your security requirements.
For details, please visit Security Groups.
Recommendations
- Apply the principle of least privilege
- Deny all inbound traffic by default
- Allow only required ports and protocols
- Restrict access by source IP wherever possible
- Regularly review and audit security group rules
Example: Recommended Restrictive Configuration
Use case: A compute instance hosting 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 may be allowed by default. You should restrict outbound access if not required by your workload.
Example: Database Server (Internal Access Only)
Use case: A database instance (e.g., MySQL or PostgreSQL) that must only be accessible from the internal application network and not from 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 only what is required 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: 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 is particularly useful for enforcing consistent security policies across multiple workloads and for segmentation of network traffic.
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 multiple workloads - You need network segmentation or perimeter firewalling
Best Practice
Security Groups and FWaaS are complementary and can be used together:
- Security Groups provide first-line, instance-level protection
- FWaaS enforces network-wide security policies and segmentation
Combining both helps achieve a defense-in-depth security model.
Common Misconfigurations
The following configurations significantly increase 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 SysEleven monitors or blocks insecure customer configurations