Skip to main content
Version: Release 24.3

Bitnami Secure Images Breaking Changes for Kubernetes Operator

Overview

Effective August 28th, 2025, Bitnami will evolve its public catalog to offer a curated set of hardened, security-focused images under the new Bitnami Secure Images initiative. This impacts customers running the Digital.ai Release Kubernetes Operator only. Customers running Release on VMs or in the cloud using non-Kubernetes methods (such as EC2 images) are not impacted.

Critical Impact

This change only affects customers running Release using the Kubernetes Operator. Bitnami images are optional and not essential to running Release. They are provided for convenience and out-of-the-box services (for example, PostgreSQL, RabbitMQ, Nginx, init containers, Helm chart hooks). Most production setups use external databases, queues, and ingress controllers.

What's Changing

Starting August 28th, 2025:

  1. Bitnami's public catalog will transition to curated, hardened security-focused container images
  2. Container image availability will be restricted for certain images used by the Kubernetes Operator
  3. Image pull policies and registry configurations may need to be updated

Which Bitnami Containers Are Provided by the Operator?

  • PostgreSQL Container: Not recommended for production; use external DB (Postgres, Oracle, or cloud DB service like Amazon RDS)
  • RabbitMQ: Provided for convenience; can connect to external queue. Release dropped RabbitMQ requirement in 25.3
  • Nginx: Used as Ingress; typically customers use their own Ingress
  • Init Container: Helper containers to set up volume permissions
  • Helm Chart Hooks: Pre-install steps for license generation or self-signed certificate

How to Check If Your Installation Is Impacted

Bitnami images may not be used in your setup. For example, Digital.ai's own SaaS environment does not use Bitnami images. To check if you are impacted:

  1. Use kubectl with the context of the cluster where Release is installed.
  2. Run the following command to discover containers with Bitnami images:
kubectl get pods -n <namespace> -o jsonpath="{range .items[*]}{.metadata.namespace}{'\t'}{.metadata.name}{'\t'}{range .spec.containers[*]}{.image}{'\n'}{end}{end}" | grep bitnami

Example output:

digitalai    dai-xld-postgresql-0    docker.io/bitnami/postgresql:17.4.0-debian-12-r17
digitalai dai-xld-rabbitmq-0 docker.io/bitnami/rabbitmq:4.0.9-debian-12-r1
  1. Run the following command to discover init containers with Bitnami images:
kubectl get pods -n <namespace> -o jsonpath="{range .items[*]}{.metadata.namespace}{'\t'}{.metadata.name}{'\t'}{range .spec.initContainers[*]}{.image}{'\n'}{end}{end}" | grep bitnami

Example output:

digitalai    dai-xld-postgresql-0    docker.io/bitnami/os-shell:12-debian-12-r43
digitalai dai-xld-rabbitmq-0 docker.io/bitnami/os-shell:12-debian-12-r43
docker.io/bitnamilegacy/rabbitmq:4.0.9-debian-12-r1

If you see Bitnami images in your pod containers or init containers, your installation is impacted.

Transition and Workaround

The following options describe how to handle Bitnami image changes and ensure your Release installation continues to function after August 28th, 2025.

For Customers Upgrading Before August 28th, 2025

Upgrade to the latest Maintenance Release (MR) (for example, 25.1.4, 24.3.10) which uses the Bitnami Legacy repository. During upgrade, all images previously using the Bitnami repository will be replaced with Bitnami Legacy. Before upgrade, update the Custom Resource (CR) with the following patch:

kubectl patch -n digitalai digitalaireleases.xlr.digital.ai dai-xlr \
--type=merge --patch '{"spec": {"global": {"security": {"allowInsecureImages": true}}}}'

If you have customized images in your CR, manually replace the Bitnami repository with Bitnami Legacy.

For Customers Not Upgrading Before August 28th, 2025

Apply the following patch script to use the Bitnami Legacy repository for all Bitnami images in the operator. This must be done before August 28th, otherwise any pod restart will fail due to unavailable image tags.

cat << EOF >> bitnami-legacy-patch.yaml
spec:
global:
security:
allowInsecureImages: true
hooks:
getLicense:
image:
repository: bitnamilegacy/kubectl
genSelfSigned:
image:
repository: bitnamilegacy/kubectl
volumePermissions:
image:
repository: bitnamilegacy/os-shell
nginx-ingress-controller:
image:
repository: bitnamilegacy/nginx-ingress-controller
defaultBackend:
image:
repository: bitnamilegacy/nginx
postgresql:
image:
repository: bitnamilegacy/postgresql
volumePermissions:
image:
repository: bitnamilegacy/os-shell
rabbitmq:
image:
repository: bitnamilegacy/rabbitmq
volumePermissions:
image:
repository: bitnamilegacy/os-shell
EOF
kubectl patch -n digitalai digitalaireleases.xlr.digital.ai dai-xlr \
--type=merge --patch-file bitnami-legacy-patch.yaml

Migration Steps

The following steps will help you prepare for and execute a successful migration or patch to avoid disruption from Bitnami image changes.

Before August 28th, 2025

  1. Audit your current deployment (see above for commands)
  2. Backup your current configuration
  3. Plan your migration or patch strategy
  4. Test the migration or patch in a non-production environment

Migration Process

  1. Update the Operator configuration or apply the patch as described above
  2. Apply the new configuration or patch
  3. Verify all pods are running with new images
  4. Test application functionality thoroughly

Timeline

DateAction Required
Before August 28, 2025Plan and complete mitigation or migration strategy
August 28, 2025Bitnami Secure Images initiative begins (mitigation must already be complete)
30 Days After August 28Validate stability and complete any remaining migration tasks

Troubleshooting

Use the following troubleshooting guidance to resolve common issues and recover from disruptions related to Bitnami image changes.

Common Issues

Image Pull Failures:

kubectl describe pod <pod-name>
# Look for ImagePullBackOff or ErrImagePull events

Solution:

  • Update image registry configuration
  • Verify network connectivity to new registry
  • Check authentication credentials if using private registry

Operator Upgrade Failures:

xl kube upgrade --debug

Solution:

  • Review operator logs for specific error messages
  • Ensure all custom resource definitions are updated
  • Validate RBAC permissions for new registry access

Additional Resources

Support

For assistance with this migration:

  1. Review this documentation and related operator guides
  2. Test migrations in non-production environments first
  3. Contact Digital.ai Support if you encounter issues during migration
  4. Engage with your DevOps team to plan the migration timeline
Important Note

This breaking change affects the underlying container infrastructure and is external to Digital.ai Release software. However, proper planning and execution of the migration steps will ensure continuity of your Kubernetes-based deployments.