mountpoint-s3-csi-driver-fips

packaged by Chainguard

Chainguard Container for mountpoint-s3-csi-driver-fips

FIPS-enabled build of the Mountpoint CSI driver, which presents an Amazon S3 bucket as a storage volume accessible by containers in your Kubernetes cluster.

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/mountpoint-s3-csi-driver-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

Comparable to the upstream Amazon S3 CSI driver image, with the same entrypoint, layout, and MOUNTPOINT_BIN_DIR contract, so it is a drop-in replacement for it.

The difference is the crypto. The image runs two programs that use different validated modules:

• The Go binaries -- the driver, controller, and mounters -- take their crypto from the system OpenSSL FIPS provider, falling back to the validated Go Cryptographic Module if it is unavailable.
• mount-s3, which performs the S3 transfers, is a Rust program whose AWS CRT stack is linked against AWS-LC in FIPS mode rather than the system OpenSSL. Its TLS is restricted to FIPS-approved key-exchange groups.

Because the two use different modules, a check that only tampers with the OpenSSL configuration will not exercise mount-s3.

FIPS support

For more information on FIPS support in Chainguard container images, please see: FIPS-enabled Chainguard Containers on Chainguard Academy.

Prerequisites

• A Kubernetes cluster, and AWS credentials the driver can use to reach S3; see upstream's credential guide.
• Pull credentials for cgr.dev/ORGANIZATION. These need to reach two separate places: the driver workloads in kube-system, and the Mountpoint Pods the controller creates in their own namespace (mount-s3 by default). The chart's imagePullSecrets covers only the first, and the Mountpoint Pods take their pull secrets from the service account they run as, so the second is a step you have to do yourself after installing -- see Getting Started.

Getting Started

Create the pull secret in kube-system first, so the driver workloads can pull:

kubectl create secret docker-registry cgr-pull --namespace kube-system \
  --docker-server=cgr.dev --docker-username=<user> --docker-password=<token>

Then a values file. The sidecar tags matter: left unset they fall back to the chart's eksbuild tags, which exist on public.ecr.aws but not on cgr.dev, so the pods would fail to pull. Create values.yaml:

cat > values.yaml <<EOF
image:
  repository: cgr.dev/ORGANIZATION/mountpoint-s3-csi-driver-fips
  tag: latest
imagePullSecrets:
  - cgr-pull
# The node DaemonSet also runs two upstream sidecars. Point them at the FIPS builds
# too, or they stay on public.ecr.aws images outside this image's FIPS boundary.
sidecars:
  nodeDriverRegistrar:
    image:
      repository: cgr.dev/ORGANIZATION/kubernetes-csi-node-driver-registrar-fips
      tag: latest
  livenessProbe:
    image:
      repository: cgr.dev/ORGANIZATION/kubernetes-csi-livenessprobe-fips
      tag: latest
EOF

Install into kube-system, as upstream does:

helm repo add aws-mountpoint-s3-csi-driver https://awslabs.github.io/mountpoint-s3-csi-driver
helm repo update
helm upgrade --install aws-mountpoint-s3-csi-driver --namespace kube-system \
  --values values.yaml aws-mountpoint-s3-csi-driver/aws-mountpoint-s3-csi-driver

The chart sets the controller's MOUNTPOINT_IMAGE from the same image, so the Mountpoint Pods that run mount-s3 use this image too. That matters: mount-s3 is where the S3 TLS and SigV4 crypto happens, so leaving those Pods on another image would put the FIPS-relevant work outside this one.

Those Pods pull as their own service account, so give it the secret after installing -- the chart creates the mount-s3 namespace, and pre-creating it stops Helm adopting it:

kubectl create secret docker-registry cgr-pull --namespace mount-s3 \
  --docker-server=cgr.dev --docker-username=<user> --docker-password=<token>

kubectl patch serviceaccount default --namespace mount-s3 \
  -p '{"imagePullSecrets": [{"name": "cgr-pull"}]}'

That is the default service account unless a volume sets mountpointPodServiceAccountName, in which case patch that one instead.

Installing as an EKS add-on

The add-on installs AWS's own images. Overriding them takes more work than the Helm path and is easier to get wrong, so prefer Helm where you can.

The add-on schema has no imagePullSecrets, so nothing gives the kube-system pods cgr.dev credentials -- without this they land in ImagePullBackOff:

kubectl create secret docker-registry cgr-pull --namespace kube-system \
  --docker-server=cgr.dev --docker-username=<user> --docker-password=<token>

kubectl patch serviceaccount s3-csi-driver-sa --namespace kube-system \
  -p '{"imagePullSecrets": [{"name": "cgr-pull"}]}'
kubectl patch serviceaccount s3-csi-driver-controller-sa --namespace kube-system \
  -p '{"imagePullSecrets": [{"name": "cgr-pull"}]}'

Then replace the images. Five changes, because each container is configured separately and the Mountpoint Pods are configured by an environment variable rather than an image field:

kubectl set image daemonset/s3-csi-node -n kube-system \
  s3-plugin=cgr.dev/ORGANIZATION/mountpoint-s3-csi-driver-fips:latest \
  node-driver-registrar=cgr.dev/ORGANIZATION/kubernetes-csi-node-driver-registrar-fips:latest \
  liveness-probe=cgr.dev/ORGANIZATION/kubernetes-csi-livenessprobe-fips:latest

kubectl set image deployment/s3-csi-controller -n kube-system \
  s3-csi-controller=cgr.dev/ORGANIZATION/mountpoint-s3-csi-driver-fips:latest

kubectl set env deployment/s3-csi-controller -n kube-system \
  MOUNTPOINT_IMAGE=cgr.dev/ORGANIZATION/mountpoint-s3-csi-driver-fips:latest

Without the last, the controller keeps spawning Mountpoint Pods from AWS's non-FIPS image, and the data path -- where the S3 TLS and SigV4 crypto runs -- is not FIPS at all. The Mountpoint Pods still need the mount-s3 service-account secret described under Getting Started.

These are all values the add-on manages, so a later update with --resolve-conflicts OVERWRITE resets them to AWS's images. Use --resolve-conflicts PRESERVE on updates, or install with Helm instead, where the values file survives upgrades.

Documentation and Resources

• Upstream installation guide
• Mountpoint for Amazon S3 CSI driver on AWS docs
• 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.