Cloud Foundry Security Groups: A Technical Overview

What Cloud Foundry Security Groups Are

Cloud Foundry security groups are a networking feature that lets platform operators define egress firewall rules for application containers. Unlike traditional security groups in infrastructure-as-a-service environments, Cloud Foundry security groups operate at the Diego cell level and apply to all application containers on a given cell, or to specific spaces and organizations when scoped appropriately. They are a core part of the Cloud Foundry security model, sitting alongside role-based access control, network policies, and container isolation to limit what traffic a running application can initiate outward.

In practice, a security group is a set of JSON-encoded rules that specify allowed or denied traffic based on protocol, port, and destination CIDR. When an app starts, the platform merges the security groups assigned to its space (and, optionally, its organization) with the default cell-level rules, then applies the resulting policy to the container's network stack via the container runtime.

How Security Groups Fit the Cloud Foundry Architecture

Security groups are enforced by the Garden container runtime on each Diego cell. Garden reads the security group rules at container creation time and translates them into Linux iptables or nftables rules, depending on the cell configuration. The Cloud Controller (CC) stores security group definitions and their associations with organizations and spaces, pushing the effective rule set to the cell during app staging and runtime.

A typical flow looks like this:

• An operator defines a security group JSON file with egress rules.
• The operator binds that security group to a space or to the default running security group for a cell.
• When an app in that space starts, Diego merges the security group with any others in scope.
• Garden applies the merged rules to the container's network namespace before the app process begins listening.

Default vs. Custom Security Groups

Cloud Foundry ships with a default running security group that permits outbound traffic on common ports such as DNS (UDP 53), HTTP (TCP 80), HTTPS (TCP 443), and SMTP (TCP 25). This default group is automatically applied to all spaces unless overridden. Operators can also define custom security groups for specific use cases, such as allowing database access on a private subnet, permitting outbound calls to an internal API, or restricting egress entirely for compliance-sensitive workloads.

Key attributes of a security group definition include the direction (egress only), protocol (tcp, udp, icmp, or all), destination (CIDR range or named tag), and port range. Cloud Foundry also supports logging of blocked connections when the diego agent is configured to emit audit logs, which helps operators validate that rules behave as intended.

Configuring Security Groups

Security groups are managed through the Cloud Foundry Command Line Interface (cf CLI) or the Cloud Controller API. Operators use commands such as cf create-security-group to upload a JSON rule file, cf bind-security-group to associate a group with a space or org, and cf set-running-security-group to define the default cell-level rules. The JSON structure is straightforward, but the order of rules matters because Cloud Foundry processes them sequentially and applies the first matching rule.

Common configuration patterns include:

• A highly restrictive group that denies all egress except to approved internal endpoints.
• A staging security group that permits access to binary download repositories and package registries.
• A runtime group that allows apps to reach internal services such as Redis or PostgreSQL on private IP ranges.

Security Groups and Multi-Tenancy

Because Cloud Foundry is a multi-tenant platform, security groups are a primary mechanism for enforcing tenant isolation at the network layer. An operator can bind different rules to different organizations so that one team's workloads cannot reach another team's databases, even if they share the same Diego cells. When combined with internal routing isolation and space-level service bindings, security groups add a defense-in-depth layer that limits blast radius if an application is compromised.

Best Practices for Cloud Foundry Security Groups

Effective security group management starts with a clear egress policy. Operators should audit which destinations each space needs and write rules as narrowly as possible, avoiding broad CIDR ranges such as 0.0.0.0/0 unless absolutely necessary. Logging and periodic reviews of security group bindings help catch drift as teams add new services or change topologies. It is also worth noting that security groups only govern egress; ingress traffic is controlled through router mappings, internal routes, and external load balancers, so a complete network policy for an app requires attention to both directions.

Finally, because security groups are applied at the cell level, scaling considerations matter. A very large number of rules or frequent changes can increase the time Diego cells spend syncing policies, which may affect app start times. Keeping rule sets lean and well-organized pays off in both security posture and operational responsiveness.