Restrict access to the internal network on garden

[gowrisankar22]

Hi colleagues,

Security Caveats says we can restrict access to the internal network on the garden.
https://concourse-ci.org/teams-caveats.html

I am not quite sure what are those ips mentioned in hh. What ips we should restrict(?) and allow(network subnet or mastercidr)?
https://github.com/concourse/hush-house/blob/master/deployments/with-creds/workers/values.yaml#L30-L36

for the production use case what ips we should restrict?

[cirocosta]

I am not quite sure what are those ips mentioned in hh. What ips we should
restrict(?) and allow(network subnet or mastercidr)?

aaaaallll of them!

just kidding - tbh, that depends a lot on your topology, e.g., in the case of
our pool of workers that run the PRs, we block from the network level the access
of those workers altogher:

https://github.com/concourse/hush-house/blob/master/deployments/with-creds/ci-pr/templates/network-policy.yaml

so that we end up with

namespace ci
	web pods
	worker pods

namespace ci-pr
	worker pods to run PRs
		--> can only reach the `ci`'s web pods, and "internet"

achieving that through network policies that get consumed by calico, which then
enforces those policies.

as not everyone is on k8s, we suggested there in the docs to use garden's
network configs: given that at the moment of creating a container, guardian
takes care of setting up networking too, one could leverage that to set up extra
rules to filter traffic.

e.g., in hush-house, aside from the network policies, we also configure
Guardian to disallow requests from the containers it creates to GCP's metadata
server (which lives under a single IP: 169.254.169.254)

- name: CONCOURSE_GARDEN_DENY_NETWORK
value: "169.254.169.254/32"

but that could be anything (e.g., 192.168.10.0/24).

---

I'm not sure if this really answers your question - it's quite impossible to
tell what you should block / not, because it depends completely on whether you
have systems in your internal network that your workloads should access or not.

personally, I tend to take a more "zero-trust networks" approach where rathre
than trying to access via boundaries, focus more on blocking access from
authorization & authentication.

I hope the (quite convoluted) answer helps!