kubernetes-pause-fips

packaged by Chainguard

Chainguard Container for kubernetes-pause-fips

Production-Grade Container Scheduling and Management

Chainguard Containers are regularly-updated, secure-by-default container images.

Download this Container Image

For those with access, this container image is available on cgr.dev:

docker pull cgr.dev/ORGANIZATION/kubernetes-pause-fips:latest

Be sure to replace the ORGANIZATION placeholder with the name used for your organization's private repository within the Chainguard Registry.

Compatibility Notes

This module publishes FIPS variants of the Kubernetes control plane components (kubernetes-kube-apiserver-fips, kubernetes-kube-controller-manager-fips, kubernetes-kube-scheduler-fips, and kubernetes-kube-proxy-fips) and of the pod infrastructure container, kubernetes-pause-fips. Each is comparable to its counterpart under registry.k8s.io and is designed to be a drop-in replacement for it.

The kubernetes-kube-apiserver-fips image runs the API server that fronts the cluster datastore and terminates TLS for every client, controller, and kubelet in the cluster. The kubernetes-kube-controller-manager-fips image runs the built-in controllers and signs the certificates issued by the cluster certificate authority. The kubernetes-kube-scheduler-fips image assigns pending pods to nodes. The kubernetes-kube-proxy-fips image programs the node-level iptables, nftables, or IPVS rules that back Services.

Those four components are Go binaries built with a FIPS-enabled Go toolchain, so their cryptography is delegated to the validated OpenSSL FIPS provider that ships in the image instead of to Go's native crypto. They accept the upstream flag surface, but where upstream wraps each binary in /go-runner, these images use the binary itself as the entrypoint (/usr/bin/kube-apiserver, /usr/bin/kube-controller-manager, /usr/bin/kube-scheduler, and /usr/local/bin/kube-proxy), so static pod manifests, DaemonSets, and kubeadm configurations that set command: keep working once the image reference is swapped. Like their upstream counterparts they run as root, because kube-proxy programs host network rules and the control plane components read host-mounted certificates and manifests.

The kubernetes-pause-fips image runs as uid 65532 (non-root); current upstream registry.k8s.io/pause (3.10.x) runs as 65535:65535, also non-root but a different uid. Its binary is a statically linked C program that holds the pod network namespace and reaps orphaned children, and it performs no cryptography of its own. The FIPS variant is built from the kubernetes-pause-fips package and ships the FIPS-hardened OpenSSL configuration and validated provider that the rest of this image group relies on, so a cluster whose sandbox image must come from a FIPS image set can use it without carving out an exception.

FIPS Support

The kubernetes-fips Chainguard Containers ship with a validated redistribution of OpenSSL's FIPS provider module. For more on FIPS support in Chainguard Containers, consult the guide on FIPS-enabled Chainguard Containers on Chainguard Academy.

Getting Started

Run the control plane components

Each control plane image is entrypointed on its own binary and accepts the upstream flags, so you can confirm which release an image carries before wiring it into a cluster:

docker run --rm cgr.dev/ORGANIZATION/kubernetes-kube-apiserver-fips:latest --version

The same applies to kubernetes-kube-controller-manager-fips, kubernetes-kube-scheduler-fips, and kubernetes-kube-proxy-fips.

In a kubeadm cluster, the control plane runs as static pods whose images kubeadm derives from a single imageRepository. Because these images do not follow that naming convention, override each static pod image with a kubeadm patch instead. Write one patch file per component into a patch directory:

mkdir -p /etc/kubernetes/patches
for component in kube-apiserver kube-controller-manager kube-scheduler; do
  cat > "/etc/kubernetes/patches/${component}+json.json" <<EOF
[{"op": "replace", "path": "/spec/containers/0/image", "value": "cgr.dev/ORGANIZATION/kubernetes-${component}-fips:1.37"}]
EOF
done

Pin the minor-version tag to the version of kubeadm running the cluster. The latest tag tracks the newest stream, so using it here would install that stream's control plane regardless of the kubeadm version in use.

Point kubeadm at that directory when you initialize or upgrade the control plane:

kubeadm init --patches /etc/kubernetes/patches
# on upgrade; then rerun the kube-proxy `set image` below
kubeadm upgrade apply <version> --patches /etc/kubernetes/patches

kube-proxy ships as a DaemonSet rather than a static pod, so set its image on the workload directly:

kubectl -n kube-system set image daemonset/kube-proxy kube-proxy=cgr.dev/ORGANIZATION/kubernetes-kube-proxy-fips:1.37

Configure the sandbox image

Using the Chainguard kubernetes-pause-fips image requires changing the containerd configuration on the nodes. If you have set up SSH access to the underlying nodes of the cluster, then you can edit the containerd configuration file directly. If you do not have access to the nodes, then you can use a plugin called kubectl-node-shell.

In the containerd configuration on the node, replace the default sandbox image with the Chainguard pause image. The key differs by config version, so check the version field at the top of /etc/containerd/config.toml first.

Under a version = 2 config, as used by containerd 1.x, set sandbox_image:

version = 2

[plugins."io.containerd.grpc.v1.cri"]
sandbox_image = "cgr.dev/ORGANIZATION/kubernetes-pause-fips:latest"

Under a version = 3 config, as used by containerd 2.x, that key is ignored and the setting moves to sandbox in the images plugin:

version = 3

[plugins.'io.containerd.cri.v1.images'.pinned_images]
sandbox = "cgr.dev/ORGANIZATION/kubernetes-pause-fips:latest"

Restart the containerd service to pick up the change:

sudo systemctl restart containerd

Listing the containers with ctr shows the pause container running the Chainguard pause image:

ctr -n k8s.io containers list

Documentation and Resources

• Kubernetes documentation
• kube-apiserver reference
• kube-controller-manager reference
• kube-scheduler reference
• kube-proxy reference
• Customizing components with the kubeadm API
• The almighty pause container
• FIPS-enabled Chainguard Containers

What are Chainguard Containers?

Chainguard's free tier of Starter container images are built with Wolfi, our minimal Linux undistro.

All other Chainguard Containers are built with Chainguard OS, Chainguard's minimal Linux operating system designed to produce container images that meet the requirements of a more secure software supply chain.

The main features of Chainguard Containers include:

• Minimal design, without unnecessary software bloat
• Daily builds to ensure container images are up-to-date with available security patches
• High quality build-time SBOMs attesting to the provenance of all artifacts within the image
• Verifiable signatures provided by Sigstore
• Reproducible builds with Cosign and apko (read more about reproducibility)

For cases where you need container images with shells and package managers to build or debug, most Chainguard Containers come paired with a development, or -dev, variant.

In all other cases, including Chainguard Containers tagged as :latest or with a specific version number, the container images include only an open-source application and its runtime dependencies. These minimal container images typically do not contain a shell or package manager.

Although the -dev container image variants have similar security features as their more minimal versions, they include additional software that is typically not necessary in production environments. We recommend using multi-stage builds to copy artifacts from the -dev variant into a more minimal production image.

Need additional packages?

To improve security, Chainguard Containers include only essential dependencies. Need more packages? Chainguard customers can use Custom Assembly to add packages, either through the Console, chainctl, or API.

To use Custom Assembly in the Chainguard Console: navigate to the image you'd like to customize in your Organization's list of images, and click on the Customize image button at the top of the page.

Learn More

Refer to our Chainguard Containers documentation on Chainguard Academy. Chainguard also offers VMs and Libraries — contact us for access.

Trademarks

This software listing is packaged by Chainguard. The trademarks set forth in this offering are owned by their respective companies, and use of them does not imply any affiliation, sponsorship, or endorsement by such companies.