This document provides an overview of network requirements for using Chainguard Images and Chainguard Enforce. To use Chainguard products in environments with firewalls, VPNs, and IDS/IPS systems, you will need to add some rules to allow traffic into and out of your networks.
This table lists the DNS hostnames, associated ports, and protocols that will need to be allowed through firewalls and proxies to use Chainguard Images:
Note that to be able to authenticate with the enforce.dev domain, you will need to ensure access to and from the following CIDR ranges:
This table lists the third-party DNS hostnames, associated ports, and protocols that will need to be allowed through firewalls and proxies to use Chainguard Images:
Note: you can use either the single 9236a389bd48b984df91adc1bc924620.r2.cloudflarestorage.com host or the wildcard *.rc.cloudflarestorage.com hostname in your firewall and proxy configurations. However, the 9236a389bd48b984df91adc1bc924620.r2.cloudflarestorage.com hostname may change at some point in the future.
Whether you are working with public or private registries, ensure that outbound connections from the Enforce agent (running in the gulfstream namespace) are permitted. Also be sure to allow the corresponding return traffic if you are using symmetric firewall rules.
If you are using Enforce in agentless mode, you will need to ensure that your registry is publicly accessible to the agent. Refer to the CIDR Ranges section of this page for a list of ranges to add to your firewall rules or access control lists.
Enforce needs access to any registry or registries that are configured for your cluster or containers so that it can validate images and policies. Depending on your environment, you will need to configure your firewalls and access control lists to allow Enforce access.
This table lists the DNS hostnames, associated ports, and protocols that will need to be allowed to communicate with your Kubernetes cluster or clusters.
For cluster and workload discovery to work, and to be able to communicate effectively to and from Chainguard Enforce, you will need to ensure access to and from the following CIDR ranges.
If you are using Google GKE for your cluster, this page explains how to authorize our networks: Add an authorized network to an existing cluster.
If you are using Amazon EKS then refer to Amazon EKS cluster endpoint access control.
Client traffic for each of the *.enforce.dev domains can be identified by the following JA3 fingerprint data:
Connections to the hosts listed on this page are generally initiated as new outbound connections. If you are using stateful firewall rules, then you will need to add symmetric rules to ensure that traffic flows correctly.
You will need egress rules that allow new traffic to the hosts listed here. You will need corresponding ingress rules that allow related and established traffic.
For the CIDR ranges listed here, ensure that you allow incoming connections from those networks. These IPs are used for workload discovery on public clouds.
Many of the hosts listed on this page use multiple DNS A records or CNAME aliases. Additionally, many A records have a short time to live of 60 seconds, and the majority are less than an hour (3600s).
If your network filters traffic based on IP addresses, ensure that any firewalls update their rules at an appropriate interval to match the TTL for each DNS record.