whereabouts-fips

packaged by Chainguard

Chainguard Container for whereabouts-fips

Whereabouts is a simple IPAM (IP Address Management) solution for Kubernetes, built with FIPS-validated cryptography. To get more information about Whereabouts, please visit the official project repository.

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/whereabouts-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 image is a FIPS-enabled build of Whereabouts. cgr.dev/ORGANIZATION/whereabouts-fips covers the same CNI IPAM plugin and ip-control-loop controller as cgr.dev/ORGANIZATION/whereabouts and the upstream ghcr.io/k8snetworkplumbingwg/whereabouts:latest, and it ships the /whereabouts and /ip-control-loop paths the daemonset install expects. It does not include the upstream /ip-reconciler or /node-slice-controller binaries. Since v0.9.4 scheduled IP reconciliation runs only in /ip-reconciler (upstream's reconciler-deployment.yaml), so leaked IP allocations are not reclaimed on a schedule with this image.

Like the upstream image it runs as root (UID 0), because the Whereabouts daemonset installs the CNI plugin binary onto the host's /opt/cni/bin and writes CNI config to /etc/cni/net.d, both of which need a privileged, root-run installer. One difference worth calling out is the launch configuration. Upstream sets /install-cni.sh as the CMD with no ENTRYPOINT, whereas this image sets /install-cni.sh as the ENTRYPOINT, so a workload that overrides only args (rather than command) will behave differently here than it would against the upstream image.

FIPS Support

The whereabouts and ip-control-loop (controlloop) binaries in this image are compiled with a Go toolchain that routes cryptography through a validated OpenSSL FIPS provider module, and falls back to its embedded, validated Go Cryptographic Module when OpenSSL FIPS is unavailable. The image ships the hardened OpenSSL FIPS configuration (openssl-config-fipshardened), which applies to ip-control-loop running in the container. The daemonset copies the whereabouts IPAM plugin to the node's /opt/cni/bin, where the container runtime executes it on the host. Unlike the statically linked upstream plugin, it is dynamically linked against glibc, so nodes must provide glibc. On the node it uses the OpenSSL FIPS provider when one is configured, and the Go module otherwise. For more on FIPS support in Chainguard Containers, consult the guide on FIPS-enabled Chainguard Containers on Chainguard Academy.

Getting Started

There is an official Whereabouts documentation that provides detailed information on how to deploy and configure Whereabouts.

ip-control-loop watches NetworkAttachmentDefinition resources and stays blocked on cache sync until that CRD exists. Install Multus CNI, which provides the CRD, before deploying Whereabouts.

To deploy Whereabouts, apply the manifests from the doc/crds directory of the official repository:

git clone https://github.com/k8snetworkplumbingwg/whereabouts && cd whereabouts
kubectl apply \
    -f doc/crds/daemonset-install.yaml \
    -f doc/crds/whereabouts.cni.cncf.io_ippools.yaml \
    -f doc/crds/whereabouts.cni.cncf.io_overlappingrangeipreservations.yaml

Then patch the image to use the Chainguard FIPS image:

kubectl -n kube-system patch daemonset whereabouts --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/imagePullPolicy", "value":"IfNotPresent"}]'
kubectl -n kube-system set image daemonset/whereabouts whereabouts=cgr.dev/ORGANIZATION/whereabouts-fips:latest

To test the deployment, you can create a pod with a network attachment definition:

The following example assumes you have deployed Multus CNI in your cluster (k8snetworkplumbingwg/multus-cni), that the macvlan CNI plugin is installed in /opt/cni/bin on your nodes, and that master names an interface that exists on your nodes.

cat <<'EOF' | kubectl apply -f -
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: whereabouts-conf
spec:
  config: '{
      "cniVersion": "0.3.0",
      "name": "whereaboutsexample",
      "type": "macvlan",
      "master": "eth0",
      "mode": "bridge",
      "ipam": {
        "type": "whereabouts",
        "range": "192.168.2.225/28"
      }
    }'
EOF

Then create a deployment that uses the network attachment definition:

cat <<'EOF' | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: netshoot-deployment
  labels:
    app: netshoot-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: netshoot-pod
  template:
    metadata:
      annotations:
        k8s.v1.cni.cncf.io/networks: whereabouts-conf
      labels:
        app: netshoot-pod
    spec:
      containers:
      - name: netshoot
        image: nicolaka/netshoot
        command:
          - sleep
          - "3600"
        imagePullPolicy: IfNotPresent
EOF

After creating the deployment, the pod should come up with an IP address assigned from the Whereabouts range on its net1 interface:

kubectl exec deploy/netshoot-deployment -- ip -brief addr show net1

net1@if7         UP             192.168.2.225/28

You have now deployed the FIPS build of Whereabouts and assigned an IP address to a pod.

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.