CI worker network egress

Workshop CI runners implement egress traffic control to protect your code and data from exfiltration.

The basic settings are controlled with the workshop-egress.yml file found in the root of your _namespace-configuration project. These settings allow you to configure the allow and deny lists that are applied to the CI workers and the services: that support those workers.

Once set, these hostnames can be accessed from your CI jobs by sending requests through proxies that are defined in the jobs with the http_proxy and https_proxy environment variables.

Valid options

The following keys can be used within workshop-egress.yml

technologies

technologies: takes a list of technology names. This list selects which entires from our technologies list will be added to the allowlist for both workers and services.

worker_allowlist

worker_allowlist: takes a list of hostnames, optionally with a * wildcard prefix. These hostnames will be allowed from CI workers, which are the machines that run the job before_script, script, and after_script.

worker_denylist

worker_denylist: also takes a list of hostnames, optionally with a * wildcard prefix. These hostnames are checked first and will deny access from the CI workers even if that hostname also matches an entry in the worker_allowlist.

This can be useful if you have a wildcard prefix in your allowlist and want to deny a particular set of subdomains.

service_egress_allowlist

service_egress_allowlist: operates the same as worker_allowlist but applies to jobs' supporting services.

service_egress_denylist

service_egress_denylist: operates the same as the worker_denylist but applies to the jobs' supporting services.

Example

workshop-egress.yml

---
# allow access to common hosts related to these technologies for both
# workers and services
technologies:
  - ruby
  - node
  - terraform
  - cloud_gov

# allow access to any app using the default cloud.gov route
worker_allowlist:
  - "*.app.cloud.gov"

# deny access to this host before checking `worker_allowlist`
worker_denylist:
  - host.app.cloud.gov

# don't add any additional hostnames to the allowlist for services
service_egress_allowlist: []

# don't allow access to the `cloud_gov` entries from services
service_egress_denylist:
  - "*.fr.cloud.gov"
  - packages.cloudfoundry.org

Troubleshooting

My job doesn't support connecting to a proxy at all

Some software does not work well with sending requests over an egress proxy. If this is your situation, send a message to workshop-support@cloud.gov requesting access to a worker that has unlimited outbound network access and we can have a conversation about your best path forward.

Egress from my services is still being blocked

You must make a one-time support request to enable any egress from your services. In that request, please include a list of ports that services should be allowed to communicate with. For instance, port 80 will allow http:// connections and port 443 will allow https:// connections.

I added an entry to my allowlist, but the request is still being blocked

There is a delay between updating your workshop-egress.yml file and that file being applied to the running proxy. Please try again after some time has passed.

If it is still being blocked, send a message to workshop-support@cloud.gov to ask us to look into the status of your egress settings.