-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add new spaces for egress when creating a new org #181
base: main
Are you sure you want to change the base?
Conversation
When we say Also, wondering if the use of |
@mheadd |
I think using |
Updated to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀
I will put this into a holding pattern until we get production tests passing from cloud-gov/deploy-cf#580 |
Before merging this, one thing to consider that I have run into when testing. When new spaces are created they are automatically in the ~$ cf bind-security-group public_networks_egress ORGs --lifecycle staging --space SPACE This way, the app will run in the |
We could also provide examples of vendoring deps so this wouldn't be necessary and I think this is the recommended approach. |
@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. |
@apburnes Apologies for any confusion. When I initially tried that on a |
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:
<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 downsecurity considerations
Will improve egress control for tenant apps