# Chainguard Containers network requirements URL: https://chainguard-docs-preview-git-okta-scim-update.chainguard.app/chainguard/containers/registry/network-requirements.md Last Modified: October 8, 2026 Tags: Chainguard Containers, Reference Using Chainguard Containers with firewalls, access control lists, and proxies. This document provides an overview of network requirements for using [Chainguard Containers](https://www.chainguard.dev/chainguard-images?utm_source=cg-academy&utm_medium=referral&utm_campaign=dev-enablement). To use Chainguard tools and Containers 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's container images do not call Chainguard services while running, so no network changes would be required to the runtime environment. Review the **Notes** column for more info on each Hostname. ## Chainguard Containers hosts This table lists the DNS hostnames, associated ports, and protocols that will need to be allowed through firewalls and proxies to use Chainguard Containers: | Hostname | Port | Protocol | IP | Notes | |-------------------------|------|----------|---------|---------------------------------------| | cgr.dev | 443 | HTTPS | v4 | Main container image registry | | console.chainguard.dev | 443 | HTTPS | v4 | Chainguard dashboard | | data.chainguard.dev | 443 | HTTPS | v4 | Console API endpoint | | console-api.enforce.dev | 443 | HTTPS | v4 | Registry API endpoint | | enforce.dev | 443 | HTTPS | v4 | Registry authentication | | dl.enforce.dev | 443 | HTTPS | v4 | `chainctl` downloads | | issuer.enforce.dev | 443 | HTTPS | v4 | Registry STS (Security Token Service) | | apk.cgr.dev | 443 | HTTPS | v4 | Package repository | | virtualapk.cgr.dev | 443 | HTTPS | v4 | Package repository | | packages.cgr.dev | 443 | HTTPS | v4 | Package repository (Extra packages) | | packages.wolfi.dev | 443 | HTTPS | v4 & v6 | Package repository (Free containers) | | tarballs.cgr.dev | 443 | HTTPS | v4 | Upstream source archives referenced by SBOM `downloadLocation` fields | | auth.chainguard.dev | 443 | HTTPS | v4 | Social login, reached by the browser that completes the login | Most of these hosts are needed to pull containers and packages. `tarballs.cgr.dev` is the exception: it is only needed if you resolve the source archives that Chainguard SBOMs point at. Where an upstream project has no stable, downloadable source archive, Chainguard mirrors a source tarball and records that URL as the package's SPDX `downloadLocation`. Tooling that follows those URLs (source-provenance checks, license and compliance scanners, air-gapped source mirroring) needs egress to this host. Container and package pulls do not. The two social login hosts, `auth.chainguard.dev` and `chainguard.us.auth0.com`, are reached by the browser that completes a `chainctl` login. With `--headless`, that browser can run on a different device from `chainctl`. If a proxy inspects TLS traffic, exempt the login hosts from inspection, as described in [Troubleshoot chainctl login](/platform/chainctl-usage/authentication-options/#troubleshoot-chainctl-login). > If you experience networking issues while trying to use Chainguard Containers, please ensure that your firewall allows traffic to and from these hosts, and that it doesn't have any rules to block `.dev` domains. ## Chainguard Containers 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 Containers: | Hostname | Port | Protocol | IP | Notes | |-----------------------------------------------------------|------|----------|---------|----------------------------------------------------------| | 9236a389bd48b984df91adc1bc924620.r2.cloudflarestorage.com | 443 | HTTPS | v4 & v6 | Blob storage for *.cgr.dev | | support.chainguard.dev | 443 | HTTPS | v4 | Support access for customers | | tuf-repo-cdn.sigstore.dev | 443 | HTTPS | v4 | Sigstore trust root for `chainctl` signature verification | | chainguard.us.auth0.com | 443 | HTTPS | v4 | Social login, reached by the browser that completes the login | > Note that the `9236a389bd48b984df91adc1bc924620.r2.cloudflarestorage.com` host is used to serve both image data and packages via `*.cgr.dev`. ## Ingress and egress Connections to the hosts listed on this page are generally initiated as new outbound connections. If you are using stateless 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. ## 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. ## Minimum TLS parameters requirements For guaranteed connectivity, the following TLS requirements must be at minimum supported by clients and servers communicating with Chainguard Containers and endpoints: Protocol Versions: - TLSv1.3 - TLSv1.2 TLS Cipher Suites: - TLS_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS Supported Groups: - X25519MLKEM768 - secp384r1 TLS Signature Schemes: - ecdsa_secp256r1_sha256 - rsa_pss_pss_sha256 Protocol support: - Support for encrypted HTTP/2 is required, including by any proxies in use The requirements can be approximately tested with the following OpenSSL client command: ```shell openssl s_client -cipher @SECLEVEL=2:TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 -ciphersuites TLS_AES_256_GCM_SHA384 -groups X25519MLKEM768:secp384r1 -alpn h2 -connect cgr.dev:443 < /dev/null ``` > Note that in the case of TLSv1.2 connectivity you must check the output for `Extended master secret: yes`. You can replace `cgr.dev:443` with your own deployments. Many of the endpoints for Chainguard products require support for the encrypted [HTTP/2 protocol](https://http2.github.io/). Some decrypting proxies might not support HTTP/2.

Zscaler, a popular decrypting proxy, may not support encrypted HTTP/2 traffic by default. If you are having connection issues using chainctl behind Zscaler, follow these steps to enable support for HTTP/2.

  1. Open a Support Ticket with Zscaler

    Before any UI configuration option appears you may need to contact Zscaler Support (TAC) and request that HTTP/2 support be provisioned/activated for your tenant. This is currently a backend setting only Support can toggle.

    You typically need to provide:

    This will allow HTTP/2 negotiation to be available in policies.

  2. Enable HTTP/2 in SSL Inspection Policies

    Once Support has enabled HTTP/2 on your tenant:

    1. Log in to the Zscaler Admin Portal.
    2. Navigate to Policy → SSL Inspection (or Administration → Advanced Settings depending on UI version).
    3. Edit your relevant SSL Inspection Policy.
    4. Look for the option "Enable HTTP/2" and turn it ON for the required rules/policies.

    This setting ensures Zscaler will maintain HTTP/2 where possible rather than downgrading to HTTP/1.1. You may need to enable it on multiple rules if you use granular SSL policies (for example, by URL category).

  3. Check Advanced settings for API/CLI traffic

    Zscaler has an advanced setting under Admin → Advanced that controls how non-browser (API or CLI) HTTP/2 traffic is handled. This setting is disabled by default, which means Zscaler will downgrade non-browser HTTP/2 traffic to HTTP/1.1. For chainctl usage, this must be set to Enabled.

See this Zscaler blog post for more details.

If the above approach is not available to you, you may need to reconfigure Zscaler to disable its "Block Undecryptable Traffic" setting. Another option is to configure direct (proxyless) access to HTTP/2 endpoints and use the no_proxy environment variable, depending on your IT policies. Please consult your proxy software's documentation for guidance on adjusting these settings in order to authenticate.