Understanding Application Security Groups

Page last updated:

This page assumes you are using cf CLI v6.4 or later.

Introduction

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

Note: If you are creating ASGs for the first time, see Restricting App Access to Internal PCF Components.

Application Security Groups

Application Security Groups (ASGs) are a collections of egress rules that specify the protocols, ports, and IP address ranges where app or task instances send traffic. Because ASGs define allow rules, 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.

When apps or tasks begin staging, they need traffic rules permissive enough to allow them to pull resources from the network. After an app or task is running, the traffic rules can be more restrictive and secure. To distinguish between these two security requirements, administrators can define one ASG for app and task staging, and another for app and task runtime.

To provide granular control when securing a deployment, an administrator can assign ASGs to apply to all app and task instances for the entire deployment, or assign ASGs to spaces to apply only to apps and tasks in a particular space.

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 permitting apps reach external services, operators can deploy the services into a subnet that is separate from their Cloud Foundry deployment. Then the operators can create ASGs for the apps that whitelist those service subnets, while denying access to any virtual machine (VM) hosting other apps.

For examples of typical ASGs, see the Typical Application Security Groups section of this topic.

Default ASGs

Elastic Runtime defines one default ASG, default\_security\_group. This group allows all outbound traffic from application containers on public and private networks except for the link-local range, 169.254.0.0/16, which is blocked.

WARNING: For security, Elastic Runtime administrators must modify the default ASGs so that outbound network traffic cannot access internal components.

The ASG is defined in the Cloud Controller configuration as follows:

security_group_definitions:
- name: default_security_group
  rules:
  - protocol: all
    destination: 0.0.0.0-169.253.255.255
  - protocol: all
    destination: 169.255.0.0-255.255.255.255

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 Cloud Foundry:

  • 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

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 the Procedures section of this topic.

Note: To apply a staging ASG to apps within a space, you must use the Cloud Controller (CC) API. The cf CLI cf bind-security-group command supports space-scoped running ASGs, but not space-scoped staging ASGs.

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 Required when 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, see the Using Log Management Services topic. Logging is only supported with protocol type tcp
description An optional text field for operators managing security group rules

Process for Administering ASGs

The following table outlines the flow of tasks that the administrator carries out over the lifecycle of ASGs. Procedures for each of these tasks are given in Managing ASGs with the cf CLI below.

Note: If you are creating ASGs for the first time, see Restricting App Access to Internal PCF Components.

Task For more information, see
1. Review the existing ASGs. If this is a new deployment, these consist of only the Default ASGs. View ASGs
2. Create new ASGs. Create ASGs
3. Update the existing ASGs. Update ASGs
4. Bind ASGs to an ASG set. Bind ASGs
5. If you need to delete an ASG, first unbind it, then delete it. Unbind ASGs
Delete ASGs

Managing ASGs with the cf CLI

This section provides the commands you need to create and manage ASGs.

View ASGs

Run the following cf CLI commands to view information about existing ASGs:

Command Output
cf security-groups All ASGs
cf staging-security-groups All ASGs applied to the platform-wide staging ASG set
cf running-security-groups All ASGs applied to the platform-wide running ASG set
cf security-group SECURITY-GROUP All rules in the ASG named SECURITY-GROUP, for example, cf security-group dns

Note: You can also view ASGs in Apps Manager under the Settings tab of a space or an app.

Create ASGs

To create an ASG, perform the following steps:

  1. Create a rules file: a JSON-formatted single array containing objects that describe the rules. See the following example, which allows ICMP traffic of code 1 and type 0 to all destinations, and TCP traffic to 10.0.11.0/24 on ports 80 and 443. Also see The Structure and Attributes of ASGs.

    [
      {
        "protocol": "icmp",
        "destination": "0.0.0.0/0",
        "type": 0,
        "code": 1
      },
      {
        "protocol": "tcp",
        "destination": "10.0.11.0/24",
        "ports": "80,443",
        "log": true,
        "description": "Allow http and https traffic from ZoneA"
      }
    ]
    
  2. Run cf create-security-group SECURITY-GROUP PATH-TO-RULES-FILE. Replace SECURITY-GROUP with the name of your security group, and PATH-TO-RULES-FILE with the absolute or relative path to a rules file.

In the following example, my-asg is the name of a security group, and ~/workspace/my-asg.json is the path to a rules file.

$ cf create-security-group my-asg ~/workspace/my-asg.json

After the ASG is created, you must bind it to an ASG set before it takes effect. See Bind ASGs below.

Bind ASGs

Note: Binding an ASG does not affect started apps until you restart them. To restart all of the apps in an org or a space, use the app-restarter cf CLI plugin.

To apply an ASG, you must first bind it to an ASG set.

To bind an ASG to the platform-wide staging ASG set, run cf bind-staging-security-group SECURITY-GROUP. Replace SECURITY-GROUP with the name of your security group.

Example:

$ cf bind-staging-security-group my-asg

To bind an ASG to the platform-wide running ASG set, run cf bind-running-security-group SECURITY-GROUP command. Replace SECURITY-GROUP with the name of your security group.

Example:

$ cf bind-running-security-group my-asg

To bind an ASG to a space-scoped running ASG set, run cf bind-security-group SECURITY-GROUP ORG SPACE. Replace SECURITY-GROUP with the name of your security group. Replace ORG and SPACE with the org and space where you want to bind the ASG set.

Example:

$ cf bind-security-group my-asg my-org my-space

To bind an ASG to a space-scoped staging ASG set, run the following Cloud Controller (CC) API commands:

GET /v2/security_groups/:guid/staging_spaces
PUT /v2/spaces/:guid/staging_security_groups/:security_group_guid data
PUT /v2/security_groups/:guid/staging_spaces/:space_guid
DELETE /v2/spaces/:guid/staging_security_groups/:security_group_guid  data
DELETE /v2/security_groups/:guid/staging_spaces/:space_guid
These API calls require administrator access. Additionally, the payload returned from API GET calls to /v2/spaces/ and /v2/spaces/:guid includes a link to the staging_security_groups_url.

For more information about using these CC API commands, see the Cloud Foundry API documentation.

Update ASGs

To update an existing ASG, perform the following steps.

  1. Edit the ASG rules in the JSON file.

  2. Run cf update-security-group SECURITY-GROUP PATH-TO-RULES-FILE. Replace SECURITY-GROUP with the name of the existing ASG you want to change, and PATH-TO-RULES-FILE with the absolute or relative path to a rules file.

In the following example, my-asg is the name of a security group, and ~/workspace/my-asg-v2.json is the path to a rules file.

$ cf update-security-group my-asg ~/workspace/my-asg-v2.json

Note: Updating an ASG does not affect started apps until you restart them. To restart all of the apps in an org or a space, use the app-restarter cf CLI plugin.

Unbind ASGs

Note: Unbinding an ASG does not affect started apps until you restart them. To restart all of the apps in an org or a space, use the app-restarter cf CLI plugin.

To unbind an ASG from the platform-wide staging ASG set, run cf unbind-staging-security-group SECURITY-GROUP. Replace SECURITY-GROUP with the name of your security group.

Example:

$ cf unbind-staging-security-group my-asg

To unbind an ASG from the platform-wide running ASG set, run cf unbind-running-security-group SECURITY-GROUP. Replace SECURITY-GROUP with the name of your security group.

Example:

$ cf unbind-running-security-group my-asg

To unbind an ASG from a specific space, run cf unbind-security-group SECURITY-GROUP ORG SPACE. Replace SECURITY-GROUP with the name of your security group. Replace ORG and SPACE with the org and space where you want to unbind the ASG set.

Example:

$ cf unbind-security-group my-asg my-org my-space

Delete ASGs

Note: You can only delete unbound ASGs. To unbind ASGs, see Unbind ASGs above.

To delete an ASG, run cf delete-security-group SECURITY-GROUP. Replace SECURITY-GROUP with the name of your security group.

Example:

$ cf delete-security-group my-asg 

Typical ASGs

Below are examples of typical ASGs. Configure your ASGs in accordance with your organization’s network access policy for untrusted apps.

ASG For access to
dns DNS, either public or private
public-networks Public networks, excluding IaaS metadata endpoints
private-networks Private networks in accordance with RFC-1918
load-balancers The internal Elastic Runtime load balancer and others
internal-proxies Internal proxies
internal-databases Internal databases

DNS

To resolve hostnames to IP addresses, apps require DNS server connectivity, which typically use port 53. Administrators should create or update a dns ASG with appropriate rules. Administrators may further restrict the DNS servers to specific IP addresses or ranges of IP addresses.

Example dns ASG:

[
  {
    "protocol": "tcp",
    "destination": "0.0.0.0/0",
    "ports": "53"
  },
  {
    "protocol": "udp",
    "destination": "0.0.0.0/0",
    "ports": "53"
  }
]

Public Networks

Apps often require public network connectivity to retrieve app dependencies, or to integrate with services available on public networks. Example app dependencies include public Maven repositories, NPM, RubyGems, and Docker registries.

Note: You should exclude IaaS metadata endpoints, such as 169.254.169.254, because the metadata endpoint can expose sensitive environment information to untrusted apps. The public_networks example below accounts for this recommendation.

Example public_networks ASG:

[
  {
    "destination": "0.0.0.0-9.255.255.255",
    "protocol": "all"
  },
  {
    "destination": "11.0.0.0-169.253.255.255",
    "protocol": "all"
  },
  {
    "destination": "169.255.0.0-172.15.255.255",
    "protocol": "all"
  },
  {
    "destination": "172.32.0.0-192.167.255.255",
    "protocol": "all"
  },
  {
    "destination": "192.169.0.0-255.255.255.255",
    "protocol": "all"
  }
]

Private Networks

Network connections that are commonly allowable in private networks include endpoints such as proxy servers, Docker registries, load balancers, databases, messaging servers, directory servers, and file servers. Configure appropriate private network ASGs as appropriate. You may find it helpful to use a naming convention with private_networks as part of the ASG name, such as private_networks_databases.

Note: You should exclude any private networks and IP addresses that app and task instances should not have access to.

Example private_networks ASG:

[
  {
    "protocol": "tcp",
    "destination": "10.0.0.0-10.255.255.255",
    "ports": "443"
  },
  {
    "protocol": "tcp",
    "destination": "172.16.0.0-172.31.255.255",
    "ports": "443"
  },
  {
    "protocol": "tcp",
    "destination": "192.168.0.0-192.168.255.255",
    "ports": "443"
  }
]

Marketplace Services

Each installed Marketplace Service requires its own set of ASG rules to function properly. See the installation instructions for each installed Marketplace Service to determine which ASG rules it requires. For more information about how to provision and integrate services, see the Services Overview topics.

About the ASG Creator Tool

The ASG Creator is a command line tool that you can use to create JSON rules files. The ASG Creator lets you specify IP addresses, CIDRs, and IP address ranges that you want to disallow traffic to, as well as the addresses that you want to allow traffic to. Based on these disallow/allow (exclude/include) lists that you provide as input, the ASG Creator formulates a JSON file of allow rules.

In turn, the JSON file is the input for the cf bind-security-group command that creates an ASG.

You can download the latest release of the ASG Creator from the Cloud Foundry incubator repository on Github: https://github.com/cloudfoundry-incubator/asg-creator/releases/latest

ASG Logging

Tracing application logs can aid in troubleshooting and debugging. These logs provide granular information, including the application’s:

  • name
  • space_url
  • space name
  • organization_url
  • organization name
  • container_id
  • process_guid

Configure the Rules File

To trace application logs, set the log attribute to true in the rules file. In the context of ASG Logging, a rules file is a JSON file that describes the rules for your Application Security Groups.

For more information about configuring the rules file and creating Application Security Groups, see the “Create ASGs” section of the topic.

Below is a code sample from an example rules file. In this example, the rules file is configured to forward requests to 10.87.35.105 through the syslog server.

  [ 
    { 
      "protocol": "tcp", 
      "destination": "10.87.35.105", 
      "ports":"80",   
      "log": true, 
      "description": "Allow apps to reach gorouter" 
    } 
  ]

Trace the Traffic Logs of a Single IP

Obtaining the app name, space_url, space name, organization_url, and organization name is a sequential and interdependent process.

First, the operator must obtain the container_id. The operator can then use the container_id to obtain the process_guid. The process_guid is then queried to obtain the space_url. The space_url is then queried to obtain the space name and organization_url. Finally, the organization_url is queried to obtain the organization name.

Step 1. Obtain the container_id

Run the grep command and specify the IP address that you want to audit to generate the desired log entry and related container_id:

$ grep “DST= IP_ADDRESS”

Example below:

$ grep “DST= 10.193.79.30”

10.193.79.42.log:Jun 20 23:05:03 10.193.79.42 kern kernel [job=diego_cell index=2] [1122561.945562] d08bb414-cdba-4381-412a-e9eccIN=wbrdg-0afe0008 OUT=eth0 MAC=4e:b7:a4:74:e2:45:0a:5a:66:81:1f:1d:08:00 SRC=10.254.0.10 DST=10.193.79.30 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=60879 DF PROTO=TCP SPT=42630 DPT=80 WINDOW=28280 RES=0x00 SYN URGP=0

In the above terminal output, the container_id is bolded. The container_id is a 31 character unique ID that allows operators to trace back to the application. The containder_id, as shown above, precedes “IN” in log entries. Operators must query the container_id to obtain the process_guid.

Step 2: Obtain the process_guid

Run the grep command in conjunction with the container_id in the following way to obtain the process_guid:

$ grep CONTAINER_ID | grep “vcap.rep” | grep process_guid

Example below:

  $ grep d08bb414-cdba-4381-412a-e9ecc 10.193.79.42.log| grep "vcap.rep" | grep process_guid

  Jun 22 13:07:52 10.193.79.42 user vcap.rep [job=diego_cell index=2]  {"timestamp":"1498136872.889604807",
  "source":"rep","message":"rep.executing-container-operation.ordinary-lrp-processor.process-reserved-
  container.run-container.containerstore-run.node-run.action.run-step.process-exit","log_level":1,
  "data":{"cancelled":true,"container-guid":"d08bb414-cdba-4381-412a-e9eccdcedb40","container-state":
  "reserved","exitStatus":143,"guid":"d08bb414-cdba-4381-412a-e9eccdcedb40","lrp-instance-key"
  :{"instance_guid":"d08bb414-cdba-4381-412a-e9eccdcedb40","cell_id":"diego_cell-2"},"lrp-key"
  :{"process_guid":"4ccbb24c-268e-421a-9d1b-3678b6eb40d0-4a2fe5af-5d55-4c0e-b720-5e2a8ee686a3","
  index":0,"domain":"cf-apps"},"process":"56c9d

The process_guid string in the resulting output is comprised of 73 characters, inclusive of dashes.

Step 3. Obtain the app name and space_url.

Run the cf curl command in conjunction with the process_guid to obtain the app name and space_url. You only need the first 36 characters of the process_guid to complete this step.

$ cf curl /v2/apps/PROCESS_GUID

Example below:

  $ cf curl /v2/apps/4ccbb24c-268e-421a-9d1b-3678b6eb40d0

  {
  "metadata": 
  "guid": "4ccbb24c-268e-421a-9d1b-3678b6eb40d0",      
  "url": "/v2/apps/4ccbb24c-268e-421a-9d1b-3678b6eb40d0",
  "created_at": "2017-06-16T23:13:55Z",
  "updated_at": "2017-06-20T22:56:40Z"
  },
  "entity": {
  "name": "proxy",
  "production": false,
  "space_guid": "c65add41-d85b-4823-9e2a-545a5e0e5812",
  "stack_guid": "9dad41b8-3043-48da-acf4-e1d4a700ea88",
  "
  "ports": [
     8080
  --- snip ---

  ],
  "space_url": "/v2/spaces/c65add41-d85b-4823-9e2a-545a5e0e5812",
  "stack_url": "/v2/stacks/9dad41b8-3043-48da-acf4-e1d4a700ea88",
  "routes_url": "/v2/apps/4ccbb24c-268e-421a-9d1b-3678b6eb40d0/routes",
  "events_url": "/v2/apps/4ccbb24c-268e-421a-9d1b-3678b6eb40d0/events",
  "service_bindings_url": "/v2/apps/4ccbb24c-268e-421a-9d1b-3678b6eb40d0/service_bindings",
  "route_mappings_url": "/v2/apps/4ccbb24c-268e-421a-9d1b-3678b6eb40d0/route_mappings"
  } 

Step 4. Obtain the space name and organization_url

Run the cf curl command in conjunction with the space_url in the following way to obtain the space name and organization_url:

$ cf curl /v2/spaces/SPACE_URL

Example below:

  $ cf curl /v2/spaces/c65add41-d85b-4823-9e2a-545a5e0e5812

  {
  "metadata": {
  "guid": "c65add41-d85b-4823-9e2a-545a5e0e5812",
  "url": "/v2/spaces/c65add41-d85b-4823-9e2a-545a5e0e5812",
  "created_at": "2017-06-16T18:14:40Z",
  "updated_at": null
  },
  "entity": {
  "name": "s",
  "organization_guid": "2c279d6c-6f15-4cc0-99ed-72ef76ec50eb",
  "space_quota_definition_guid": null,
  "allow_ssh": true,
  "organization_url": "/v2/organizations/2c279d6c-6f15-4cc0-99ed-72ef76ec50eb",
  "developers_url": "/v2/spaces/c65add41-d85b-4823-9e2a-545a5e0e5812/developers",
  "managers_url": "/v2/spaces/c65add41-d85b-4823-9e2a-545a5e0e5812/managers",
  "auditors_url": "/v2/spaces/c65add41-d85b-4823-9e2a-545a5e0e5812/auditors",
  "apps_url": "/v2/spaces/c65add41-d85b-4823-9e2a-545a5e0e5812/apps",
  "routes_url": "/v2/spaces/c65add41-d85b-4823-9e2a-545a5e0e5812/routes",
  "domains_url": "/v2/spaces/c65add41-d85b-4823-9e2a-545a5e0e5812/domains",
  "service_instances_url": "/v2/spaces/c65add41-d85b-4823-9e2a-545a5e0e5812/service_instances",
  "app_events_url": "/v2/spaces/c65add41-d85b-4823-9e2a-545a5e0e5812/app_events",
  "events_url": "/v2/spaces/c65add41-d85b-4823-9e2a-545a5e0e5812/events",
  "security_groups_url": "/v2/spaces/c65add41-d85b-4823-9e2a-545a5e0e5812/security_groups" 

Step 5: Obtain the organization name

Run the cf curl command in conjunction with the organization_url in the following way to obtain the organization name:

$ cf curl /v2/organizations/ORGANIZATION_URL

Example below:

  $ cf curl /v2/organizations/2c279d6c-6f15-4cc0-99ed-72ef76ec50eb 

  {
  "metadata": {
  "guid": "2c279d6c-6f15-4cc0-99ed-72ef76ec50eb",
  "url": "/v2/organizations/2c279d6c-6f15-4cc0-99ed-72ef76ec50eb",
  "created_at": "2017-06-16T18:14:19Z",
  "updated_at": null
  },
  "entity": {
  "name": "o",
  "billing_enabled": false,
  "quota_definition_guid": "6002a805-f285-4e7b-8ff6-cd4ac607d26e",
  "status": "active",
  "quota_definition_url": "/v2/quota_definitions/6002a805-f285-4e7b-8ff6-cd4ac607d26e",
  "spaces_url": "/v2/organizations/2c279d6c-6f15-4cc0-99ed-72ef76ec50eb/spaces",
  "domains_url": "/v2/organizations/2c279d6c-6f15-4cc0-99ed-72ef76ec50eb/domains",
  "private_domains_url": "/v2/organizations/2c279d6c-6f15-4cc0-99ed-72ef76ec50eb/private_domains",
  "users_url": "/v2/organizations/2c279d6c-6f15-4cc0-99ed-72ef76ec50eb/users",
  "managers_url": "/v2/organizations/2c279d6c-6f15-4cc0-99ed-72ef76ec50eb/managers",
  "billing_managers_url": "/v2/organizations/2c279d6c-6f15-4cc0-99ed-72ef76ec50eb/billing_managers",
  "auditors_url": "/v2/organizations/2c279d6c-6f15-4cc0-99ed-72ef76ec50eb/auditors",
  "app_events_url": "/v2/organizations/2c279d6c-6f15-4cc0-99ed-72ef76ec50eb/app_events",
  "space_quota_definitions_url": "/v2/organizations/2c279d6c-6f15-4cc0-99ed-72ef76ec50eb/space_quota_definitions"
  }
  }

Auditing Deleted Apps

If an app has been deleted, cf curl /v2/apps/PROCESS_GUID yields an output similar to the following:

  {
  "description": "The app could not be found: 4ccbb24c-268e-421a-9d1b-3678b6eb40d0", 
  "error_code": "CF-AppNotFound", 
  "code": 100004 
  }

Call the events endpoint in conjunction with the process_guid to obtain historical information from an app that has since been deleted. The events record catalogues past events and as such cannot give operators the most up-to-date information on their applications. These events are also eventually removed from the system.

To call the events record run the cf curl command in the following way: $ cf curl /v2/events?q=actee:CONTAINER_ID.

The resulting terminal output will contain the space_guid, organization_guid, and other relevant information.

Example below:

  $ cf curl /v2/events?q=actee:4ccbb24c-268e-421a-9d1b-3678b6eb40d0
  {
  "total_results": 6,
  "total_pages": 1,
  "prev_url": null,
  "next_url": null,
  "resources": [
  {
  "metadata": {
  "guid": "d343a7dc-8882-4529-b3b9-83677ee2017e",
  "url": "/v2/events/d343a7dc-8882-4529-b3b9-83677ee2017e",
  "created_at": "2017-06-16T23:13:55Z",
  "updated_at": null
  },
  "entity": {
  "type": "audit.app.create",
  "actor": "7b2d6421-db00-4a1d-86d3-dc07edbe8afd",
  "actor_type": "user",
  "actor_name": "admin",
  "actee": "4ccbb24c-268e-421a-9d1b-3678b6eb40d0",
  "actee_type": "app",
  "actee_name": "proxy",
  "timestamp": "2017-06-16T23:13:55Z",
  "metadata": {
  "request": {
  "name": "proxy",
  "space_guid": "c65add41-d85b-4823-9e2a-545a5e0e5812",
  "memory": 32,
  "disk_quota": 32,
  "buildpack": "go_buildpack",
  "environment_json": "PRIVATE DATA HIDDEN",
  "console": false,
  "docker_credentials_json": "PRIVATE DATA HIDDEN",
  "health_check_type": "port",
  "instances": 1,
  "production": false,
  "state": "STOPPED"
  }
  },
  "space_guid": "c65add41-d85b-4823-9e2a-545a5e0e5812",
  "organization_guid": "2c279d6c-6f15-4cc0-99ed-72ef76ec50eb"
  }
  --snip--

Trace the Traffic Logs of a CIDR Range

To trace logs from a CIDR Range, set the destination attribute in the rules file as a range of addresses.

Example below:

  [ 
    { 
      "protocol": "tcp", 
      "destination": "0.0.0.0-0.0.0.255", 
      "ports":"80",   
      "log": true, 
      "description": "Allow apps to reach gorouter" 
    } 
  ]

Use the same method outlined in the Tracing the Traffic Logs of a Single IP section of this page to obtain the app name, space_url, space name, organization_url, organization name, container_id, and process_guid for a CIDR range.

Create a pull request or raise an issue on the source for this page in GitHub