crossplane-function-kcl-fips

packaged by Chainguard

Chainguard Container for crossplane-function-kcl-fips

This composition function runs KCL programs, inline or from OCI and git module sources, to generate and patch composed resources in a Crossplane composition pipeline, built with FIPS-validated cryptography.

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/crossplane-function-kcl-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

The Chainguard crossplane-function-kcl-fips container image is a drop-in replacement for the upstream function-kcl Crossplane package published at xpkg.upbound.io/crossplane-contrib/function-kcl. The image ships the function binary together with the Crossplane package metadata and the KCLInput CRD in /package.yaml, so you can reference it directly in a Function resource. Like the upstream image, it uses /function as the entrypoint and sets KCL_PKG_PATH and KCL_CACHE_PATH to /tmp.

The image differs from upstream in the following ways:

• It is built on Chainguard OS instead of the Debian-based kcllang/kcl image, which removes the operating system packages that account for most of the upstream image's vulnerabilities.
• It runs as the nonroot user with UID 65532 instead of root.
• The KCL runtime library is built from source and loaded from /usr/lib/libkcl.so, instead of being extracted from the function binary into KCL_LIB_HOME at startup. The function no longer needs a writable KCL_LIB_HOME directory.
• It does not include the standalone kcl command-line tool, which the function does not use.

In addition, this FIPS variant uses FIPS-validated cryptography through OpenSSL:

• The function's gRPC server only negotiates FIPS-approved TLS cipher suites.
• The KCL runtime fetches OCI modules over TLS through OpenSSL instead of the rustls and ring libraries.
• The KCL crypto.sha1, crypto.sha224, crypto.sha256, crypto.sha384, crypto.sha512, and crypto.filesha256 functions hash through OpenSSL.

The KCL crypto.md5 and crypto.blake3 functions have no FIPS-approved equivalent and are computed outside the FIPS module. Avoid them in compositions that must use only FIPS-approved algorithms.

Prerequisites

You need a Kubernetes cluster with Crossplane v2.0 or later installed. If Crossplane is not installed yet, install it with Helm:

helm repo add crossplane-stable https://charts.crossplane.io/stable
helm repo update
helm install crossplane --namespace crossplane-system --create-namespace crossplane-stable/crossplane

Getting Started

Create a Function resource that points at the Chainguard image:

cat > function.yaml <<EOF
apiVersion: pkg.crossplane.io/v1
kind: Function
metadata:
  name: function-kcl
spec:
  package: cgr.dev/ORGANIZATION/crossplane-function-kcl-fips:latest
EOF
kubectl apply -f function.yaml

Wait for Crossplane to install the function and report it as healthy:

kubectl wait --for=condition=Healthy function.pkg.crossplane.io/function-kcl --timeout=300s

Configuration

Composition steps pass KCL code to the function through a KCLInput. The program reads the composite resource (XR) from option("params").oxr and returns the resources it wants Crossplane to manage in items. Returning a patched copy of option("params").dxr updates the XR itself, which is a convenient way to surface computed values in its status.

The following Composition computes three status fields for an XGreeting composite resource whose spec has name and replicas fields:

cat > composition.yaml <<EOF
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: kcl-greeting
spec:
  compositeTypeRef:
    apiVersion: example.io/v1alpha1
    kind: XGreeting
  mode: Pipeline
  pipeline:
    - step: render-status
      functionRef:
        name: function-kcl
      input:
        apiVersion: krm.kcl.dev/v1alpha1
        kind: KCLInput
        spec:
          source: |
            import crypto

            oxr = option("params").oxr
            dxr = {
                **option("params").dxr
                status.greeting = "Hello, " + oxr.spec.name
                status.doubled = oxr.spec.replicas * 2
                status.digest = crypto.sha256(oxr.spec.name)
            }
            items = [dxr]
EOF
kubectl apply -f composition.yaml

Inline source keeps the logic next to the Composition, which suits short programs. For larger programs, set source to an OCI or git module reference instead, and list shared KCL modules under spec.dependencies using the [dependencies] syntax of a kcl.mod file:

spec:
  dependencies: |
    k8s = "1.31"
  source: oci://ghcr.io/kcl-lang/crossplane-xnetwork-kcl-function

The function downloads module dependencies into the directory set by KCL_PKG_PATH and keeps its KCL cache under KCL_CACHE_PATH, both of which default to /tmp in this image, the same as upstream. Git-sourced modules are fetched with the bundled git client, which also supports ssh:// and git@ URLs through the bundled OpenSSH client.

Documentation and Resources

• function-kcl on GitHub
• KCL documentation
• Crossplane composition functions

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.