App Security Groups
This topic provides an overview of App Security Groups (ASGs) in Pivotal Web Services (PWS), and describes how to manage and administer them.
ASGs are a collection of egress rules that specify the protocols, ports, and IP address ranges where app or task instances send traffic.
ASGs define allow rules, and their order of evaluation is unimportant when multiple ASGs apply to the same space or deployment. The platform sets up rules to filter and log outbound network traffic from app and task instances. ASGs apply to both buildpack-based and Docker-based apps and tasks.
Admins can define a
staging ASG for app and task staging, and a
running ASG for app and task runtime.
When apps or tasks begin staging, they require traffic rules permissive enough to allow them to pull resources from the network. A running app or task no longer needs to pull resources, so traffic rules can be more restrictive and secure. To distinguish between these two security requirements, admins can define a
staging ASG for app and task staging with more permissive rules, and a
running ASG for app and task runtime with less permissive rules.
To provide granular control when securing a deployment, admins can assign platform-wide ASGs that apply to all app and task instances for the entire deployment, or space-scoped ASGs that apply only to apps and tasks in a particular space.
In environments with both platform-wide and space-specific ASGs, the ASGs for a particular space are combined with the platform ASGs to determine the effective rules for that space. Any of the permitted traffic in the set of applicable ASGs is then effectively permitted for that app.
ASGs can be complicated to configure correctly, especially when the specific IP addresses listed in a group change.
To simplify securing a deployment while still allowing apps reach external services, operators can deploy the services into a subnet that is separate from their PWS deployment, then create ASGs for the apps that allow those service subnets, while denying access to any VM hosting other apps.
For examples of typical ASGs, see Typical ASGs.
ASGs are applied by configuring ASG sets differentiated by scope, platform-wide or space specific, and lifecycle, staging or running.
Currently, four ASG sets exist in PWS:
- Platform-wide staging ASG set, also called “default-staging”
- Platform-wide running ASG set, also called “default-running”
- Space-scoped staging ASG set
- Space-scoped running ASG set
In environments with both platform-wide and space-specific ASG sets, combine the ASG sets for a particular space with the platform ASG sets to determine the rules for that space.
The following table indicates the differences between the four sets:
|When an ASG is bound to the…||the ASG rules are applied to…|
|Platform-wide staging ASG set||the staging lifecycle for all apps and tasks.|
|Platform-wide running ASG set||the running lifecycle for all app and task instances.|
|Space-scoped staging ASG set||the staging lifecycle for apps and tasks in a particular space.|
|Space-scoped running ASG set||the running lifecycle for app and task instances in a particular space.|
Typically, ASGs applied during the staging lifecycle are more permissive than the ASGs applied during the running lifecycle. This is because staging often requires access to different resources, such as dependencies.
You use different commands to apply an ASG to each of the four sets. For more information, see Managing ASGs with the cf CLI.
Note: To apply a staging ASG to apps within a space, you must use cf CLI v6.28.0 or later.
ASG rules are specified as a JSON array of ASG objects. An ASG object has the following attributes:
||A single IP address, an IP address range like
||A single port, multiple comma-separated ports, or a single range of ports that can receive traffic. Examples:
||Only possible if
||ICMP code||Required when
||Logging is only supported with protocol type
||An optional field for operators managing ASG rules|