Network Requirements

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.

Chainguard Images

Images Hosts

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:

35.230.121.20/32,34.132.193.40/32,35.237.242.37/32,34.117.0.114/32,34.107.162.32/32

Images Third-party Hosts

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.

Chainguard Enforce

Enforce Agent Access

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.

Enforce Image Registry Access

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.

Enforce Chainguard Hosts

This table lists the DNS hostnames, associated ports, and protocols that will need to be allowed to communicate with your Kubernetes cluster or clusters.

Enforce Third-party Hosts

Enforce CIDR Ranges

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.

35.230.121.20/32,34.132.193.40/32,35.237.242.37/32,34.117.0.114/32,34.107.162.32/32

Enforce JA3 Fingerprints

Client traffic for each of the *.enforce.dev domains can be identified by the following JA3 fingerprint data:

Fullstring

771,49195-49199-49196-49200-52393-52392-49161-49171-49162-49172-156-157-47-53-49170-10-4865-4866-4867,0-5-10-11-13-65281-16-18-43-51,29-23-24-25,0

Fingerprint

3fed133de60c35724739b913924b6c24

Ingress and Egress

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.

DNS Records and TTLs

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.