tekton-entrypoint-geomys-fips

packaged by Chainguard

Chainguard Container for tekton-entrypoint-geomys-fips

Statically linked Tekton entrypoint built with the native Go FIPS 140-3 module, so the binary Tekton copies into every TaskRun pod runs in musl-based step images.

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/tekton-entrypoint-geomys-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

Apart from the features listed under FIPS Support, this image replaces the Chainguard tekton-entrypoint-fips 1.15 image, used as the Tekton Pipelines entrypoint. It is built against the native Go FIPS 140-3 module (geomys) instead of the OpenSSL-backed Go FIPS toolchain, which lets the entrypoint be statically linked like upstream.

Tekton runs this image as the prepare init container of every TaskRun pod, which copies the entrypoint binary onto a volume shared with the steps; each step's command then runs through it, and this cannot be opted out of. A statically linked binary runs in any step image. The tekton-entrypoint-fips binary is linked against glibc, so it cannot be loaded at all in a musl-based step image such as Alpine (exec /tekton/bin/entrypoint: no such file or directory), and the same applies to a glibc step image older than the one it was built against.

Only the entrypoint is affected. Use this image for the controller's entrypoint-image setting and keep the controller, webhook and the other components on the existing tekton-*-fips images.

Relative to the upstream image it replaces, ghcr.io/tektoncd/pipeline/entrypoint-bff0a22da108bc2f16c818c97641a296:

• the entrypoint runs under tini (/sbin/tini -- /ko-app/entrypoint);
• the binary is installed at /usr/bin/entrypoint, with /ko-app/entrypoint as a symlink to it, rather than being the /ko-app binary itself;
• KO_DATA_PATH is unset, so anything reading kodata must set it explicitly.

All three match tekton-entrypoint-fips, so this is a drop-in for it.

FIPS Support

The entrypoint's cryptography is served entirely by the geomys native Go FIPS 140-3 module (NIST CMVP certificate #5247), with FIPS mode on by default. tekton-entrypoint-fips instead reaches the OpenSSL FIPS provider (NIST CMVP certificate #5132) through cgo. Both images ship the same set of certificate marker packages, so the installed packages do not tell them apart; the binary's build settings do — this one records CGO_ENABLED=0 and chainguard_cryptographic_module=geomys, the other CGO_ENABLED=1 and chainguard_cryptographic_module=openssl+geomys. Check which certificate your compliance paperwork cites before switching.

Every cryptographic primitive comes from the Go standard library; third-party code such as go-jose calls into it, so no functionality is removed relative to tekton-entrypoint-fips. MD5 and SHA-1 reach the binary through crypto/tls, crypto/x509, UUID generation and go-jose, and remain available because the module runs in fips140=on rather than fips140=only. TLS connections negotiate only FIPS-approved cipher suites and curves; an endpoint offering only non-approved algorithms (ChaCha20-Poly1305, curve25519 key exchange) is refused.

Getting Started

Point the Tekton Pipelines controller's entrypoint image at this image. In the upstream release manifest this is the -entrypoint-image argument on the tekton-pipelines-controller deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tekton-pipelines-controller
  namespace: tekton-pipelines
spec:
  template:
    spec:
      containers:
        - name: tekton-pipelines-controller
          image: cgr.dev/ORGANIZATION/tekton-controller-fips:1.15
          args:
            - "-entrypoint-image"
            - "cgr.dev/ORGANIZATION/tekton-entrypoint-geomys-fips:1.15"
            # -nop-image, -sidecarlogresults-image, -workingdirinit-image,
            # -shell-image and -shell-image-win must stay: Images.Validate
            # exits with "found unset image flags" if any of them is missing.

Apply it to an existing install by replacing only the entrypoint value, so the other image flags survive:

kubectl -n tekton-pipelines patch deployment tekton-pipelines-controller \
  --type=json \
  -p='[{"op":"test","path":"/spec/template/spec/containers/0/args/0","value":"-entrypoint-image"},{"op":"replace","path":"/spec/template/spec/containers/0/args/1","value":"cgr.dev/ORGANIZATION/tekton-entrypoint-geomys-fips:1.15"}]'

Steps may then use any base image, including Alpine:

apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
  name: musl-step
spec:
  taskSpec:
    steps:
      - image: alpine:3.22
        script: echo "hello from a musl step"

Documentation and Resources

• Tekton Pipelines documentation
• Upstream description of the entrypoint mechanism
• Chainguard FIPS images

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.