Chainguard Container for REPO_NAME

Minimalist Wolfi-based Keycloak IAMGuarded image for identity and access management.

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/REPO_NAME:latest

Be sure to replace the ORGANIZATION placeholder with the name used for your organization's private repository within the Chainguard Registry.

Overview

Keycloak IAMGuarded FIPS is a FIPS-compliant security-enhanced variant of Keycloak designed to be deployed using its companion IAMGuarded Helm chart. This image and chart combination includes configuration management capabilities and provides additional security benefits over standard Keycloak deployments, with full FIPS compliance.

Helm Chart Installation

The Keycloak IAMGuarded Helm chart is delivered exclusively through the same OCI registry as your Chainguard images:

cgr.dev/$ORGANIZATION/iamguarded-charts/keycloak

Basic Installation

Once authenticated (see below) you can install the chart with standard Helm commands and your organization name:

helm install keycloak oci://cgr.dev/$ORGANIZATION/iamguarded-charts/keycloak \
  --set "global.org=$ORGANIZATION"

Important: Replace $ORGANIZATION with your Chainguard organization name. The default organization in the chart values is chainguard-private, which must be changed to match your organization.

Configuration Requirements

Organization Setting

The global.org value is required and can be set either:

• Via --set flag during installation
• In your existing values.yaml file

Registry Configuration

For users who mirror images to custom repositories:

• Use global.imageRegistry to override the default cgr.dev
• For complex mirroring strategies, consult the chart's values.yaml for individual image configuration options including registry, repository, tag, and digest

Example values.yaml for individual image configuration:

# Main Keycloak FIPS image
image:
  registry: myregistry.example.com
  repository: mirrored/keycloak-iamguarded-fips
  digest: sha256:... # Use specific digest instead of tag

# Keycloak Config CLI
keycloakConfigCli:
  image:
    registry: myregistry.example.com
    repository: mirrored/keycloak-config-cli-iamguarded
    digest: sha256:... # Use specific digest instead of tag

Authentication

Ensure proper pull credentials are configured through one of the following methods:

Option 1: Using Helm values with global.imagePullSecrets

# values.yaml
global:
  imagePullSecrets:
    - name: chainguard-pull-secret

Option 2: Create a Kubernetes pull secret

# Step 1: Authenticate with chainctl and generate a pull token
chainctl auth login
chainctl auth configure-docker --pull-token --save --ttl=24h

# Step 2: Create the Kubernetes secret
kubectl create secret docker-registry chainguard-pull-secret \
  --docker-server=cgr.dev \
  --docker-username=$(echo cgr.dev | docker-credential-cgr get | jq -r '.Username') \
  --docker-password=$(echo cgr.dev | docker-credential-cgr get | jq -r '.Secret') \
  -n <your-namespace>

# Step 3: Reference the secret in your Helm installation
helm install keycloak oci://cgr.dev/$ORGANIZATION/iamguarded-charts/keycloak \
  --set "global.org=$ORGANIZATION" \
  --set "global.imagePullSecrets[0].name=chainguard-pull-secret"

Option 3: Cluster node-scoped registry permissions (cluster-dependent)

Best Practices

1. Pin to Digest: While charts follow the same tagging scheme as Chainguard images, always pin to a specific chart digest to prevent unexpected updates:

   helm install keycloak oci://cgr.dev/$ORGANIZATION/iamguarded-charts/keycloak@sha256:DIGEST \
     --set "global.org=$ORGANIZATION"

   The digest can be found in the output of helm pull e.g:

   helm pull oci://cgr.dev/$ORGANIZATION/iamguarded-charts/keycloak
   Pulled: cgr.dev/chainguard-private/iamguarded-charts/keycloak:$tag
   Digest: sha256:...

2. Review Default Values: The chart provides security-minded defaults that are sensible but may not be production-ready for all use cases. Review the chart's values.yaml (run helm show values) for the full range of configuration options.

3. Image Pinning: All IAMGuarded charts pin images to specific digests that have been tested for compatibility, ensuring reliable deployments.

Validation

After deployment, validate your Keycloak IAMGuarded FIPS installation using standard Keycloak verification methods. The deployment functions as a standard Keycloak instance with FIPS compliance, so all typical Keycloak validation procedures apply.

Prerequisites

Prerequisites are defined in the chart's Chart.yaml and individual templates. No additional requirements beyond standard Kubernetes and Helm functionality are needed.

Security Considerations

The Keycloak IAMGuarded FIPS chart provides security-minded defaults while acknowledging the cluster-specific nature of both Keycloak and Kubernetes environments. This FIPS variant ensures compliance with FIPS 140-2 standards. Review and adjust settings based on your specific security requirements and cluster configuration.

For detailed configuration options and advanced usage, refer to the chart's values.yaml file.

Prerequisites

• DB connection password must be at least 112 bits.
• A keystore file must be provided to enable FIPS mode.
• Keystore password must be at least 112 bits.

Keycloak Specific Configuration

Keycloak provides a mechanism to configure and customize the image. This process is outlined in the Keycloak image documentation.

There are subtle differences in the executable paths used in the Chainguard image. Below is the example copied from the documentation, updated with the correct paths:

FROM cgr.dev/chainguard/keycloak-iamguarded-fips:latest as builder

# Enable health and metrics support
ENV KC_HEALTH_ENABLED=true
ENV KC_METRICS_ENABLED=true

# Configure a database vendor
ENV KC_DB=postgres

WORKDIR /usr/share/java/keycloak
# for demonstration purposes only, please make sure to use proper certificates in production instead
RUN keytool -genkeypair -storepass password -storetype PKCS12 -keyalg RSA -keysize 2048 -dname "CN=server" -alias server -ext "SAN:c=DNS:localhost,IP:127.0.0.1" -keystore conf/server.keystore
RUN /opt/iamguarded/keycloak/bin/kc.sh build

FROM cgr.dev/chainguard/keycloak:latest
COPY --from=builder /usr/share/java/keycloak/ /usr/share/java/keycloak/

# change these values to point to a running postgres instance
ENV KC_DB=postgres
ENV KC_DB_URL=<DBURL>
ENV KC_DB_USERNAME=<DBUSERNAME>
ENV KC_DB_PASSWORD=<DBPASSWORD>
ENV KC_HOSTNAME=localhost
ENTRYPOINT ["/opt/iamguarded/keycloak/bin/kc.sh"]

Disclaimer

This image is equipped with the essential components for Keycloak to operate in FIPS mode. However, it's important for users to ensure they use it in line with FIPS compliance standards.

This includes tasks such as keystore generation, configuration, and launching Keycloak with the correct configuration parameters. More guidance is provided in the sections below.

Keystore

Keycloak requires a bcfips-compatible keystore to manage its SSL/TLS certificates.

Although Keycloak supports various keystore types, only BCKFS offers the capability to operate in approved (strict) mode under FIPS standards, ensuring only approved ciphers are used.

BCKFS Keystore creation

To create keystore you can use keytool from this image like so:

kubectl run -q --rm --attach create-keystore \
  --image=cgr.dev/ORGANIZATION/keycloak-iamguarded-fips --restart=Never --command -- \
    sh -c ' \
      keytool -v -keystore "/tmp/server.keystore" \
      -storetype bcfks \
      -providername BCFIPS \
      -alias "localhost" \
      -genkeypair -sigalg SHA512withRSA -keyalg RSA \
      -dname CN="localhost" \
      -storepass "<YOUR TLS KEYSTORE PASSWORD>" \
      -keypass "<YOUR TLS KEY PASSWORD, can be the same>"; \
      cat /tmp/server.keystore' > server.keystore

BCKFS Truststore creation

To create a truststore and import and trust an existing CA certificate you can also use keytool:

docker run -v $(pwd):/tmp/keystore --entrypoint keytool cgr.dev/ORGANIZATION/keycloak-iamguarded-fips \
  -v -keystore /tmp/keystore/truststore.bckfs \
  -storetype bcfks \
  -providername BCFIPS \
  -import -file /tmp/keystore/MyCA.crt \
  -storepass "<YOUR TRUSTSTORE PASSWORD>" \
  -trustcacerts \
  -noprompt

You can similarly use the keycloak container as an init container in your helm values.yaml to import certificates to a BCKFS truststore. When doing this you may need to set the environment of just the init containerJAVA_TOOL_OPTS to set the --module-path init container and configure the truststore for keycloak using the javax.net.ssl properties using JAVA_OPTS. The need for JAVA_TOOL_OPTIONS for Java tooling with the BCFIPS provider is documented in section 2.1.1 in the Bouncy Castle FIPS Java API User Guide:

extraEnvVars:
- name: JAVA_OPTS
  value: "-Djavax.net.ssl.trustStore=/opt/iamguarded/keycloak/certs/keycloak.truststore.jks -Djavax.net.ssl.trustStorePassword=changeit -Djavax.net.ssl.trustStoreType=FIPS"
  env:
  - name: JAVA_TOOL_OPTIONS
    value: "--module-path=/usr/share/java/bouncycastle-fips -Djava.class.path=/usr/share/java/bouncycastle-fips/bc-fips.jar"

** Note on --truststore-paths **

Currently it is not possible to use the --truststore-paths option when using --features=fips --fips-mode=strict, see this issue

Deployment

To deploy Keycloak on Kubernetes, you can use the iamguarded helm chart alongside the KeyCloak FIPS documentation.

You will need to do all of the prerequisites mentioned above, and then you need to pass the necessary values to the Helm chart.

Once you create your server.keystore using the BCFIPS provider, create a Secret object in your Kubernetes cluster to mount it into the Keycloak container later on:

kubectl create secret generic keycloak-keystore --from-file=server.keystore

Set the values to override the necessary fields:

cat <<EOF > keycloak_values.yaml
extraVolumes:
  - name: "keycloak-keystore"
    secret:
      secretName: "keycloak-keystore"
      items:
        - key: "server.keystore"
          path: "server.keystore"
extraVolumeMounts:
  - name: "keycloak-keystore"
    mountPath: "/usr/share/java/keycloak/conf"
    readOnly: true
auth:
  adminUser: "<ADMIN_USER>"
  adminPassword: "<ADMIN_PASSWORD>"
image:
  registry: cgr.dev
  repository: ORGANIZATION/keycloak-iamguarded-fips
  tag: latest
extraStartupArgs: "--features=fips --fips-mode=strict --https-key-store-password=<KEYSTORE_PASSWORD>"
# If using the chart's postgres, set a long password
postgresql:
  auth:
    password: <LONG_DATABASE_PASSWORD>
EOF

FIPS validation

If you want to validate the FIPS mode as we did in image tests, you can increase the log level to TRACE. You'll see debug logs such as the below if Keycloak is running in FIPS mode:

--log-level='INFO,org.keycloak.common.crypto:TRACE,org.keycloak.crypto:TRACE'

Then you will see the following logs:

trustStoreType: FIPS
FIPS-JVM: enabled
Approved Mode
BouncyCastleFipsProvider

Debugging

Invalid Keystore Format with BCFKS in production mode

Error Message:

# kc.sh start --features=fips --hostname=localhost --https-key-store-password='**********'
ERROR: Failed to start server in (production) mode
ERROR: Unable to start HTTP server
ERROR: java.io.IOException: Invalid keystore format

Solution: BCFKS Keystores default to strict mode, and it's likely you omitted --fips-mode=strict in your arguments. If you wish to run in non-strict mode with BCFKS, you need to include --https-key-store-type=bcfks.

This is called out in the official documentation, but perhaps could benefit from additional clarification.

Keystore corrupted error upon launch

Error Message:

ERROR: Unable to start HTTP server
ERROR: java.io.IOException: BCFKS KeyStore corrupted: MAC calculation failed.
ERROR: BCFKS KeyStore corrupted: MAC calculation failed.

Solution: The error indicates that a Keystore was detected, but there was an issue parsing it. Usually this means that the password used to create the keystore does not match what was provided as the --https-key-store-password argument to Keycloak.

Key material not provided error in production mode

Error Message:

ERROR: Failed to start server in (production) mode
ERROR: Key material not provided to setup HTTPS. Please configure your
keys/certificates or start the server in development mode.

Solution: This error usually indicates that a .keystore was not detected in the /usr/share/java/keycloak/conf directory. Ensure you have created a Keystore and it is accessible to the container in the expected directory.

Password must be at least 112 bits

Error Message:

Failed to add user '<admin-user>' to realm 'master': org.keycloak.models.ModelException:
password must be at least 112 bits
FipsUnapprovedOperationError: password must be at least 112 bits

Solution: This is expected whenever Keycloak is running in strict (approved) mode for FIPS. Choose a longer admin password which is compliant. Refer to the Keycloak FIPS documentation for more information.

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.