networking_monitoring.prolific

View Application Security Groups

### What?
Application Security Groups are a collection of egress (outbound) rules that specify the protocols, ports, and IP ranges where application containers can send traffic. Security groups define rules that *allow* traffic instead of omitting it, which means that the order of evaluation for security groups that apply to the same space, org, or deployment is unimportant. Application containers use these rules to filter and log outbound network traffic.

When applications begin staging, they need traffic rules permissive enough to allow them to pull resources from the network. After an application is running, the traffic rules can be more restrictive and secure. To distinguish between these two security requirements, administrators can define different security groups for *staging* containers versus *runtime* containers.

To provide granular control when securing a deployment, an administrator can also assign security groups to apply across a CF deployment, or to specific spaces or orgs within a deployment.

### How?
1. As admin view the list of security groups 
`cf security-groups`
1. View the security groups assigned to staging containers 
`cf staging-security-groups`
1. View the security groups assigned to running containers 
`cf running-security-groups`
1. View the specific rules of each group using 
`cf security-group $group_name`

#### Expected Result
If you've deployed a full Cloud Foundry on GCP you should have two security groups applied to both staging and running apps: `public_networks` and `dns`.

If you run `cf security-group public_networks` you'll see that it allows traffic on all ports with all protocols on all IPs, save four gaps that correspond to [private IPv4 address spaces](https://en.wikipedia.org/wiki/Private_network#Private_IPv4_address_spaces) and the [APIPA reserved range](https://www.pctechbytes.com/networking/fix-169-254-address-problem/). The `dns` security group allows access to any IP, but only on [port 53](https://en.wikipedia.org/wiki/Domain_Name_System#Protocol_transport). The combination of the two groups is that private IPs can be accessed only on port 53, and all other IPs have all ports open.

(If you're working with PCF Dev, you should see three security groups, one of which is named `all_pcfdev` and opens all egress traffic. Because of the `all_pcfdev` security group any other group would be redundant.)

### Resources
[Application Security Groups Documentation](https://docs.cloudfoundry.org/adminguide/app-sec-groups.html)
[Typical Application Security Groups](https://docs.cloudfoundry.org/adminguide/app-sec-groups.html#typical-groups)
["Taking Security to the Next Level—Application Security Groups" by Abby Kearns](https://blog.pivotal.io/pivotal-cloud-foundry/products/taking-security-to-the-next-level-application-security-groups)
["Making sense of Cloud Foundry security group declarations" by Sadique Ali](https://sdqali.in/blog/2015/05/21/making-sense-of-cloud-foundry-security-group-declarations/)
L: security

---

Allowing network traffic to other apps (AKA Configure container networking policies)
### What?
By default, security groups are configured not to allow app containers to address each other directly.
For example, if `app1` has IP address 10.255.11.9 and `app2` has IP address 10.255.11.14,
`app1` would fail to curl 10.255.11.14,
and `app2` would fail to curl 10.255.11.9.

[Container networking features](https://github.com/cloudfoundry/cf-networking-release) allow `cf` users
to define network policies between apps that override security groups.

Let's see how can manage the networking security of an app that needs to communicate with other apps.

### How?
Before applying a network policy
1. Make sure you have two apps pushed. If don't have any apps pushed, `cf push boots -p <PATH_TO_DORA> && cf push swiper -p <PATH_TO_DORA>`.
1. In two different terminals, `cf ssh` to boots' and swiper's application container.
1. On `swiper`, run `netstat -n` to discover it's container IP address (look under Local Address). It should have a value like 10.255.X.Y
1. On `boots`, run `curl <SWIPER_IP>:8080`.

Apply the network policy to allow access:
1. On your command line, run `cf add-network-policy boots --destination-app swiper --protocol tcp --port 8080`

See if the app containers can communicate
1. In your ssh session on boots, try this again: `curl <SWIPER_IP>:8080`
1. Now try the reverse, `curl <BOOTS_IP>:8080` on swiper

### Expected Result
The initial curl should fail. After applying the networking policy, the curl should succeed.

Poke around to see what else you can and can't do with the network policy commands.
Can you allow access to mutliple ports?
What happens if you allow access to a port that the app doesn't listen to? Is it give the same error?

### Resources
[Container networking docs](https://github.com/cloudfoundry/cf-networking-release/tree/develop/docs)
[Docs: Understanding CF Networking](https://docs.cloudfoundry.org/concepts/understand-cf-networking.html)
[Docs: Deploy Apps with CF C2C Networking](https://docs.cloudfoundry.org/devguide/deploy-apps/cf-networking.html)
[Video: CF Networking: All Your Packets are Belong to Us](https://www.youtube.com/watch?v=WrTXd42_m10)
L: security

---

Allowing network traffic to other, non-app, private IPs (AKA Making custom ASGs)
### What?
In the previous story, you used container networking policies to allow traffic between app containers. Cool beans.
But, what if you want your app to be able to establish connections with other private IP addresses that aren't apps?

If you need help thinking of a reason you'd want to do this, imagine trying to connect your app to anything that was deployed by BOSH, which mostly deploys to private IPs (which, as we've pointed out in previous stories, are blocked from app containers by default).
The most common example of this are BOSH-deployed services like [cf-mysql](https://github.com/cloudfoundry/cf-mysql-deployment).
However, rather than force you to set up another BOSH deployment, let's instead use our existing CF deployment, and see if we can't think of some CF component as a "service" that an app may want to leverage.
For the sake of this story, let's try to query the router for its list of routes (it's a thing you can do!). We'll create our own ASG to allow our app containers to open a connection to the router's private IP.

### How?
The basic outline of this workflow is this:
1. Curl the router's `/routes` endpoint from an app container, and see that the connection isn't allowed.
1. Create and bind an ASG that allows your app container to connect to the IP address of the router.
1. Try curling the `/routes` endpoint again, and see that you get successful response from the router.

Construct the URL for querying the router
In order to curl the router's `/routes` endpoint, you'll to get the router's IP address, port, as well as special credentials (username and password) for making this request. Don't worry, you can find all of this in your manifest or vars-store/Credhub.
- Router IP Address: Run `bosh instances` and look for an instance group called `router` and copy the IP address.
- Router Status Port: routing-release [sets port 8080 as the default](https://github.com/cloudfoundry/routing-release/blob/develop/jobs/gorouter/spec#L33-L35) -- unless you wrote an ops-file to override the default, you should use this port.
- Router Status Username: Again, [routing-release has provided a default](https://github.com/cloudfoundry/routing-release/blob/develop/jobs/gorouter/spec#L36-L38). Go with that, most likely.
- Router Status Password: cf-deployment uses [a BOSH variable called `router_status_password` to configure this password](https://github.com/cloudfoundry/cf-deployment/blob/2118b5d8ac09feed153f6eea552fd561dd6aa999/cf-deployment.yml#L865). The way to fetch this value depends on whether you used Credhub or a vars-store to maintain your credentials. 
  For Credhub, make sure you've run `eval "$(bbl print-env)"` (don't forget the double quotes!). Then run `credhub find -n router_status_password` to discover the full name of the variable (it will look something like `/bosh-bbl-env-something/cf/router_status_password`). Copy the full name, and run `credhub get -n $FULL_NAME` to get find the password.
  For vars-store, just grep `router_status_password` from your vars-store

Before creating the ASG:
1. Make sure you have an app pushed. If don't have one running, `cf push dora -p <PATH_TO_DORA>`.
1. `cf ssh` to dora's application container, and then run `curl router-status:$ROUTER_PASSWORD@$ROUTER_IP:8080/routes`.

Create and bind an ASG:
1. Write a file with contents like this:
  ```
  [
    {
      "protocol": "tcp",
      "destination": "$ROUTER_IP/32",
      "ports": "8080",
      "description": "Allow apps to query router-status"
    }
  ]
  ```
1. On your command line, run `cf create-security-group router-asg /PATH/TO/ASG_FILE.json`
1. Bind the ASG to the space that includes your pushed app: `cf bind-security-group router-asg $MY_ORG $MY_SPACE`
1. Restart dora to allow the ASG to take effect: `cf restart dora`

See if the app container can communicate with the router:
1. SSH back onto dora, and re-run `curl router-status:$ROUTER_PASSWORD@$ROUTER_IP:8080/routes`

### Expected Result
The initial curl should fail. After applying the security group, the curl should succeed.

Poke around to see what else you can and can't do with the ASG commands.
Can you allow access to mutliple ports?
What happens if you allow access to a port that the router doesn't listen to? Does it give the same error?

L: security

---

[RELEASE] Networking and Monitoring ⇧