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) provides policy-based perimeter firewalling applied to router ports. A firewall group combines an ingress and an egress firewall policy and is associated with one or more router ports, filtering all traffic entering and leaving them — typically the boundary between your networks and the internet.
The main resources are:
- Firewall rule — matches traffic by protocol, source/destination IP address (or CIDR) and source/destination port, and specifies an action: allow or deny.
- Firewall policy — an ordered list of firewall rules, evaluated top to bottom. An implicit deny all rule is always added at the lowest precedence, so a policy without rules blocks all traffic.
- Firewall group — associates an ingress and egress policy with the ports to protect. A group is inactive until it is associated with at least one active router port.
Note
The underlying SDN implements firewall rules as stateless ACLs. Return traffic is not allowed automatically: for every TCP/UDP service you permit, you need an ingress rule opening the destination port and an egress rule opening the source port for the response.
FWaaS applies the same policy to all traffic crossing the protected ports, so the workloads behind them are protected consistently.
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) | Router ports (perimeter of the attached networks) |
| Firewall type | Distributed, instance-level | Perimeter firewall on router ports (stateless) |
| Stateful | Yes | No — stateless ACLs; return traffic needs an explicit egress rule |
| Typical use case | Protecting single instances | Perimeter filtering at network boundaries |
| Granularity | Per instance / per port | Per attached port |
| Management | Applied directly to instances | Firewall groups associated with router ports |
| Best suited for | Workload-level access control | Perimeter firewalling between networks and the internet |
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 a single, consistent firewall policy at a network boundary
- You need to filter all traffic crossing a router's external port
- You want consistent enforcement across all workloads behind the firewall
- You need perimeter firewalling between internal networks and the internet
Best Practice
Security Groups and FWaaS operate at different layers: Security Groups protect individual compute instances, while FWaaS filters traffic at the network boundary (router ports).
Combining the two is not recommended (see the warning below). Use one or the other as the primary enforcement point for your workloads.
Warning
The underlying SDN implements FWaaS rules as stateless ACLs, while security groups are stateful by default. Combining stateful security groups with the stateless firewall rules can lead to undefined behaviour: connection tracking entries from VM ports may leak into the firewall rules applied to the router port. See the Neutron FWaaS user guide for details.
MetaKube Clusters and FWaaS Rules
Using FWaaS rules in combination with a MetaKube cluster might have unforeseen consequences on the cluster deployment and runtime.
Kubernetes clusters generate many dynamic traffic flows — communication between cluster components, health checks, DNS lookups, image pulls, and software updates — often using ephemeral source ports. Because FWaaS rules are stateless, each of these flows must be explicitly allowed in both directions. A strict policy is therefore likely to block at least one flow the cluster needs, which can break cluster components in ways that are difficult to diagnose.
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