Add new spaces for egress when creating a new org

[apburnes]

To support newly created orgs with our additional egress controls, all new orgs will have nine spaces based on three envs and each env having three egress types.

Naming suggestions for the egress types welcome!

Changes proposed in this pull request:

• Add "public", "internal", and "private" to new org spaces to allow for different egress options
  • <env>-public: Apps can send requests to the public internet and our internal service like RDS
  • <env>-internal: Apps can only send requests to the internal services: RDS, ES, Redis
  • <env>-private: Apps are locked down

security considerations

Will improve egress control for tenant apps

[mheadd]

When we say private, do we mean that an app can only communicate via c2c with another app in the same space (assuming the network policies are in place for this)?

Also, wondering if the use of internal might be confusing if conflated with internal routes. What if we used public, restricted, closed or something similar? Just a thought - happy to kick this around more.

[apburnes]

@mheadd private does mean that an app can only communicate via c2c. I like public, restricted, and closed. Should we also append -egress to be more semantic? Or is that too much?

[mheadd]

I think using -egress makes sense, @apburnes.

[apburnes]

Updated to public-egress, restricted-egress, and closed-egress

[mheadd]

🚀

[apburnes]

I will put this into a holding pattern until we get production tests passing from cloud-gov/deploy-cf#580

[mheadd]

Before merging this, one thing to consider that I have run into when testing. When new spaces are created they are automatically in the closed-egress ASG. This will prevent someone from pushing an app because of the need for the platform to fetch external dependencies - the staging process will fail. We should consider allowing the staging process to use the public-egress as the app is staged. We can do this by running:

~$ cf bind-security-group public_networks_egress ORGs --lifecycle staging --space SPACE

This way, the app will run in the closed-egress ASG and be staged in the public-egress ASG.

[davemcorwin]

We could also provide examples of vendoring deps so this wouldn't be necessary and I think this is the recommended approach.

[apburnes]

@mheadd the egress rules are only applied at runtime and not during app staging. We left app staging egress open to allow users to install dependencies.

[mheadd]

@apburnes Apologies for any confusion. When I initially tried that on a closed-egress space it didn't work, but I'm not able to replicate the issue. Disregard my prior comment.

The base branch was changed.