flink-kubernetes-operator-fips

packaged by Chainguard

Chainguard Container for flink-kubernetes-operator-fips

Apache Flink Kubernetes Operator — manages the full lifecycle of Apache Flink applications on Kubernetes.

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/flink-kubernetes-operator-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 runs the operator on a FIPS 140-3 Java runtime: BouncyCastle FIPS in approved-only mode, BCJSSE for TLS, and BCFKS for operator-side key and trust stores. PKCS12 is not usable in this image: chart-generated PKCS12 keystores fail to parse, and its keytool cannot write PKCS12 stores. A few features need FIPS-specific handling:

• Disable the admission webhook (--set webhook.create=false). The chart has cert-manager issue its keystore as PKCS12, which this runtime cannot parse. Validation is not lost — the operator applies the same rules during reconciliation, so an invalid resource is flagged on its status.error and events instead of being rejected at kubectl apply time. The limitation is the chart's certificate workflow, not the webhook: given a BCFKS keystore (WEBHOOK_KEYSTORE_FILE / WEBHOOK_KEYSTORE_TYPE=BCFKS) it serves normally, but the chart exposes no values for that, so it needs patched manifests.
• REST TLS to the JobManager requires FIPS-specific configuration on each FlinkDeployment and on the operator Deployment; Flink's default cipher (TLS_RSA_WITH_AES_128_CBC_SHA) is not offered by BCJSSE in approved-only mode. See "Configuring JobManager REST TLS" below.
• ZooKeeper HA over TLS works, with a BCFKS truststore for the operator, configured through ZooKeeper's own zookeeper.ssl.* JVM properties. Pin the TLS version on the server and the clients: Flink's bundled ZooKeeper client offers TLS 1.2 while current ZooKeeper servers default to 1.3, and they will not negotiate otherwise. This is tested with server-authenticated TLS; mutual TLS is not covered.
• ZooKeeper SASL DIGEST-MD5 is unsupported: the policy disables MD5-based SASL mechanisms.

Usage

The operator manages FlinkDeployment, FlinkSessionJob, FlinkStateSnapshot, and FlinkBlueGreenDeployment custom resources into running Flink clusters and jobs.

Installing the operator with Helm

The upstream project publishes a Helm chart alongside each release. Point the chart's image.repository at the Chainguard image and install it into the flink-operator namespace.

Each release is published as its own Helm repository. Replace OPERATOR_VERSION with the release you want (see the upstream release list).

helm repo add flink-operator-repo \
  https://downloads.apache.org/flink/flink-kubernetes-operator-OPERATOR_VERSION/

helm install flink-kubernetes-operator flink-operator-repo/flink-kubernetes-operator \
  --namespace flink-operator --create-namespace \
  --set image.repository=cgr.dev/ORGANIZATION/flink-kubernetes-operator-fips \
  --set image.tag=latest \
  --set webhook.create=false

Configuring JobManager REST TLS

The Helm install deploys the operator only. REST TLS is configured per FlinkDeployment, plus two environment variables on the operator Deployment pointing at a mounted BCFKS truststore (silently ignored if the file is absent):

env:
  - name: OPERATOR_TRUSTSTORE_PATH
    value: /opt/flink/tls-cert/truststore.jks
  - name: OPERATOR_KEYSTORE_PASSWORD
    value: <operator-truststore-password>

Each FlinkDeployment enables REST TLS, carries the JobManager keystore, and pins FIPS-approved ciphers:

apiVersion: flink.apache.org/v1beta1
kind: FlinkDeployment
metadata:
  name: example
spec:
  image: cgr.dev/ORGANIZATION/flink:latest
  flinkVersion: v1_20
  serviceAccount: flink
  flinkConfiguration:
    security.ssl.rest.enabled: "true"
    security.ssl.rest.keystore: /opt/flink/tls-cert/keystore.p12
    security.ssl.rest.keystore-type: PKCS12 # read by the JobManager, not this image
    security.ssl.rest.keystore-password: <jobmanager-keystore-password>
    security.ssl.rest.key-password: <jobmanager-keystore-password>
    security.ssl.rest.truststore-type: BCFKS # read by the operator; must be BCFKS
    # RSA server cert -> ECDHE_RSA suites; EC needs ECDHE_ECDSA
    security.ssl.algorithms: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  podTemplate:
    spec:
      containers:
        - name: flink-main-container
          volumeMounts:
            - {name: jm-tls, mountPath: /opt/flink/tls-cert}
      volumes:
        - name: jm-tls
          secret: {secretName: <jobmanager-keystore-secret>}

Without security.ssl.algorithms, BCJSSE in approved-only mode offers none of Flink's default ciphers: the operator's REST client fails with No usable cipher suites enabled and status.clusterInfo never populates — there is no plaintext fallback.

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.