GSA
[SC-7] Restrict egress traffic from inventory
This is a copy of https://github.com/GSA/data.gov/issues/3755 pared down to just the inventory apps.
User Story
In order to minimize the harm a compromised app can do, the data.gov team wants egress traffic from cloud.gov-hosted data.gov inventory applications to be limited to just expected destinations.
Acceptance Criteria
[ACs should be clearly demoable/verifiable whenever possible. Try specifying them using BDD.]
- GIVEN I am logged into cloud.gov
AND I am targeting thegsa-datagovorganization- [ ] WHEN I run
cf t -s prod-egress; cf apps
THEN I see a running instance of thecg-egress-proxyfor each app with egress needs in theprodspace. - [ ] WHEN I run
cf t -s prod; cf network-policies
THEN I see a rules allowing traffic from each app with egress needs in theprodspace to port 443 on the corresponding proxy app in theprod-egressspace.
- [ ] WHEN I run
Background
SC-7 has traditionally been hard to implement for cloud.gov apps. However, the cloud.gov team has now made it possible to drop the ASG allowing public egress traffic for particular spaces. This enables us to run our production space in the "restricted" configuration, when egress traffic is only allowed for bound services (excluding S3). We then set up dedicated egress proxies in a space with external access. Doing this also enables apps in spaces without public_egress to access S3.
cg-egress-proxy was developed for a high-profile GSA project deployed on cloud.gov that had extremely high public visibility, and was required to meet NIST control SC-7 to ensure egress/lateral compromise was not possible. However, that app did not proceed to production despite getting an ATO. As a result, data.gov might be the first team to ship a working SC-7 egress solution for cloud.gov apps. This will set a new precedent for TTS' standard cloud.gov compliance practice, so be sure to make any fixes necessary upstream in cg-egress-proxy!
Security Considerations (required)
This work will ensure egress traffic from cloud.gov-hosted data.gov apps is properly restricted by default, as required by NIST control SC-7.
Sketch
- [ ] Follow the instructions to deploy egress proxies in the
prod-egressspace based on .acl files, with network policies that allow each app to talk to the corresponding proxy- [ ] In particular, the script should be run with .acl files present corresponding to the
inventoryapps allowing them to reach the expected set of .gov/.mil/whatever domains that they crawl.
- [ ] In particular, the script should be run with .acl files present corresponding to the
- [ ] If we note any problems with apps connecting to S3 buckets after properly configuring them to use the proxy, we should work with Bret/cloud.gov support/AWS support to resolve this issue.
Currently blocked by https://github.com/cloud-gov/product/issues/1775
any update on the S3 gateway proxying blockers...? I saw that the Federalist and image repository issues seemed to be resolved...
Yes finally got an answer from AWS and need to test it out in staging. Will work on that this week.
I took a quick look at this and it seems like a very similar issue as before:
ERR botocore.exceptions.SSLError: SSL validation failed for https://s3-us-gov-west-1.amazonaws.com/cg-efc8a388-5300-46f2-97a7-62792fb14b53 [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1131)
Will look more deeply, but don't feel optimistic.
Is egress proxy working for catalog? Because if it is, there should be no platform reasons why it shouldn't work for inventory, right?
We are on different version of python and probably have some other small change that could effect this.
Egress proxy has been successfully deployed to inventory and has been live for more than a day. I feel like there should be important notes that we put here. But I can't think of anything, so hopefully the notes in the above PRs are enough.