Restrict access to the internal network on garden

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!

concourse / hush-house

Restrict access to the internal network on garden #117