Agent Requirements

EnforceProductReference

The Chainguard Enforce Agent is installed into each of your Kubernetes clusters as a StatefulSet consisting of 2 pod relicas in their own namespace called gulfstream. The Enforce Agent is a statically compiled binary, requires minimal system resources, and can be installed using a variety of tools. It supports a number of different Certified Kubernetes distributions and versions.

If you are using a managed GKE or EKS cluster, consider installing Enforce in agentless (also referred to as SaaS) mode by following this guide: Set Up Chainguard Enforce Cloud Account Associations. This installation method also supports additional workload discovery like Google Cloud Run, AWS ECS, and AWS AppRunner, and does not consume any resources in your Kubernetes clusters.

Supported Kubernetes Versions

Enforce is supported for the current stable set of Kubernetes point releases, as well as versions that are within the upstream support period.

Agent Resource Requirements

The Chainguard Enforce Agent uses the following Kubernetes resource requests and limits:

CPUMemory
Requests50m50Mi
Limits11000Mi

Note that pods can use more resources than requested, but will not exceed the specified limits. As a general benchmark, an Enforce Agent pod handling 40 requests per second will consume 250-300MB of RAM.

Private Cluster Requirements

The Chainguard Enforce Agent is required when running Enforce with private Kubernetes clusters, or when using managed GKE or EKS clusters that do not have exposed public API endpoints (the latter are also considered private to Enforce).

Network Access

The Enforce Agent running in either scenario must be able to reach our public Enforce SaaS endpoints. Refer to the Enforce Network Requirements page for a list of CIDR ranges to add to your firewalls.

Service Accounts

Clusters using the Enforce Agent are required to have Service Account Token Volume Projection and Service Account Issuer Discovery enabled.

Consult our Connect Kubernetes Clusters to Enforce page for details on how to validate your cluster configuration supports these service account settings.

Limitations of Private Clusters

When running in private clusters, the agent needs to be re-installed under two circumstances:

  • If the service account issuer signing key is rotated
  • At least every 25 days

This is accomplished by running chainctl cluster install --private once again.

Installing Enforce Agent

To install the Enforce Agent, you can use one of the following supported methods depending on your infrastructure configuration.

chainctl

You can use chainctl, which is a CLI tool to interact with, query, and manage Enforce in your clusters.

For more details on how to use chainctl to install Enforce consult our Enforce Installation with chainctl page.

YAML

You can also install Enforce Agent using YAML manifests directly. Consult the Declarative Option 1 — Install with YAML section of the Installation guide to determine which method of generating the required YAML files is appropriate for your environment.

Helm

The Enforce Agent can also be installed using a Helm chart. As noted on that page, if you choose this method, be sure to include the additional auth: fields as part of your values.yaml file.

Supported Kubernetes Versions Matrix

The Enforce agent is known to work with the following Kubernetes versions and configurations:

ProviderKubernetes VersionCPU ArchRuntime
AWS (EKS)1.23, 1.24, 1.25, 1.26x86_64containerd
Google (GKE)1.23, 1.24, 1.25, 1.26x86_64gVisor, containerd
Kubernetes (upstream)1.23, 1.24, 1.25, 1.26x86_64containerd