App Security Groups

This topic provides an overview of App Security Groups (ASGs) in Pivotal Web Services, and describes how to manage and administer them. Many of the steps below require the Cloud Foundry Command Line Interface (cf CLI) tool.

Overview

App Security Groups (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.

Staging and Running ASGs

Administrators 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, administrators 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.

Platform-Wide and Space-Scoped ASGs

To provide granular control when securing a deployment, administrators 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 application.

Simplifying ASGs with a Services Subnet

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.

ASG Sets

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 Procedures.

Note: To apply a staging ASG to apps within a space, you must use cf CLI v6.28.0 or later.

The Structure and Attributes of ASGs

ASG rules are specified as a JSON array of ASG objects. An ASG object has the following attributes:

Attribute Description Notes
protocol tcp, udp, icmp, or all Required
destination A single IP address, an IP address range like 192.0.2.0-192.0.2.50, or a CIDR block that can receive traffic
ports A single port, multiple comma-separated ports, or a single range of ports that can receive traffic. Examples: 443, 80,8080,8081, 8080-8081 Only possible if protocol is tcp or udp.
code ICMP code Required when protocol is icmp. A value of -1 allows all codes.
type ICMP type Required when protocol is icmp. A value of -1 allows all types.
log Set to true to enable logging. For more information about how to configure system logs to be sent to a syslog drain, Using Log Management Services. Logging is only supported with protocol type tcp
description An optional field for operators managing security group rules