Bitnami legacy changes force a Passbolt Helm migration rethink

At a glance

What this is: Passbolt is outlining how Bitnami’s legacy image changes affect its Helm-based deployment path and what a migration to MariaDB Operator and Valkey would change.

Why it matters: For IAM and platform teams, this is a reminder that dependency lifecycle, image provenance, and operational ownership all matter when machine identities underpin production services.

👉 Read Passbolt’s migration plan for Bitnami-dependent Helm deployments

Context

Bitnami’s change is a supply-chain and lifecycle issue, not a simple packaging update. When a deployment chart depends on external container images, the security posture of that service account, cache layer, or database layer is only as strong as the update path behind those images. For Passbolt users, the key question is how to preserve a controlled Kubernetes deployment when the upstream image source no longer offers the same maintenance model.

That matters because Helm charts often hide machine identity dependencies behind convenience. MariaDB, Redis, and similar services are not just infrastructure components, they are authenticated runtime dependencies that need version control, patch discipline, and clear offboarding when a default source changes. The transition away from Bitnami is therefore a governance test for NHI and workload identity programmes as much as a deployment decision.

Key questions

Q: What breaks when a Helm chart depends on images that move to a legacy repository?

A: The immediate break is not installation, it is trust in the maintenance model. The chart may still deploy, but teams can inherit stale images, missed security patches, and unclear upgrade accountability. That turns a convenience dependency into a lifecycle risk, especially for stateful components that support production identity services.

Q: When should organisations replace bundled Helm dependencies with owned infrastructure?

A: They should replace bundled dependencies when the upstream maintenance path no longer matches production risk tolerance. If image updates, patching, or provenance are no longer predictable, the organisation needs its own lifecycle ownership for databases, cache layers, and rollback planning before the next upgrade cycle.

Q: What do security teams get wrong about open-source replacement stacks?

A: They often assume open source reduces governance work, when it actually shifts responsibility to the operator. Community-maintained components still need version control, upgrade testing, backup verification, and ownership clarity. Without that discipline, the new stack can become just as risky as the deprecated one it replaces.

Q: Who is accountable when a deprecated dependency remains in production?

A: Accountability belongs to the team that owns the deployment lifecycle, not the upstream maintainer who changed the source model. If a deprecated dependency stays live, the organisation must own the risk, the migration timeline, and the decision to continue relying on a non-maintained image source.

Technical breakdown

What Bitnami’s legacy repository change means for Helm dependencies

A Helm chart does more than declare installation steps. It defines a dependency graph that includes image sources, chart defaults, and upgrade behaviour. When a chart points to images that move into a legacy repository, the chart may still install, but the security guarantees behind those images change materially. In practice, users can end up with pinned but stale versions, or with extra operational overhead to mirror, rebuild, and validate replacements. For stateful services like databases and caches, that creates patching and provenance pressure that the chart itself cannot solve.

Practical implication: treat dependency image sources as part of the security boundary and review them before the upstream maintenance model changes.

MariaDB Operator and Valkey as replacement building blocks

Replacing bundled Bitnami subcharts with the MariaDB Operator and Valkey shifts control from a vendor-curated image catalog to community-maintained operational components. An operator manages stateful services using Kubernetes-native reconciliation, while a Redis-compatible cache such as Valkey preserves application behaviour without inheriting the same commercial dependency path. The security value is not the brand swap. It is the ability to own provisioning, upgrades, and failover behaviour more directly. That said, early adopters inherit responsibility for configuration hardening, backup validation, monitoring, and recovery testing.

Practical implication: validate operator-driven database and cache recovery before changing defaults in production.

Why open-source defaults still need lifecycle governance

Open source does not remove lifecycle risk. It changes where responsibility sits. A community project can provide transparency and independence, but organisations still need to control image provenance, chart versions, rollback paths, and deprecation handling. In identity-adjacent systems, the real risk is assuming that open source automatically means continuously maintained or operationally safe. It does not. The governance model must still answer who owns the dependency, who approves upgrades, and what happens when a chart’s default stack changes under a production workload.

Practical implication: extend your lifecycle reviews to every Helm dependency, not just the primary application release.

NHI Mgmt Group analysis

Bitnami’s shift exposes dependency lifecycle as an identity governance issue, not just a packaging inconvenience. Passbolt users are not simply losing a convenience layer. They are being forced to confront what happens when a stateful workload depends on externally maintained images whose maintenance model changes underneath it. The implication is that machine identity governance must include upstream dependency ownership, not only local deployment configuration.

Standing trust in default images is a fragile assumption for production Kubernetes. Charts often encourage teams to treat bundled dependencies as stable infrastructure, even when the security lifecycle is controlled elsewhere. Once a source moves into a legacy state, that assumption breaks and the environment inherits stale-image risk, patch drift, and unclear operational accountability. Practitioners should treat default chart dependencies as governed assets, not as permanent fixtures.

Open-source replacement stacks only work when lifecycle responsibility is explicit. MariaDB Operator and Valkey can reduce commercial dependency lock-in, but they do not eliminate the need for provenance, upgrades, failover testing, and offboarding discipline. This is where many teams misread open source as lower governance cost when it is often simply a different governance model. The practitioner takeaway is to map ownership for every dependency before the migration, not after.

Helm-based application security now depends on the lifecycle of supporting machine identities. The application may be Passbolt, but the operational risk sits in the database and cache identities that keep it running. That makes dependency review, version pinning, and migration planning part of identity governance, not just platform engineering. Teams should align chart maintenance with their broader NHI and workload identity controls.

From our research:

• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• For related lifecycle context, see Ultimate Guide to NHIs , 2025 Outlook and Predictions for how identity governance expands as infrastructure models change.

What this signals

Dependency lifecycle is now part of identity programme scope. When a deployment chart relies on upstream images that can move into legacy status, the governance model has to include provenance, upgrade ownership, and offboarding of retired sources. Teams that already manage multiple secrets manager instances know how fragmentation erodes control, and the same pattern applies to Kubernetes dependencies.

This is where platform and identity teams should align. If your programme already maps workload identity and secret ownership, extend that model to Helm subcharts and stateful service dependencies. The operational question is no longer whether the chart installs, but whether the whole dependency chain can be sustained under your control.

For broader lifecycle framing, the NIST Cybersecurity Framework 2.0 remains a useful baseline for ownership, protection, detection, response, and recovery across changing infrastructure dependencies.

For practitioners

• Review every bundled dependency in the Helm chart Inventory the chart’s image sources, subcharts, and pinned versions, then identify which components depend on upstream maintenance models you do not control. Flag any dependency that has entered a legacy or deprecated state for migration planning.
• Define ownership for database and cache lifecycle Assign an accountable team for MariaDB or MySQL, Redis-compatible cache services, upgrade validation, and rollback readiness before changing defaults. Include backup testing, monitoring, and recovery checks in the ownership model.
• Test the replacement stack outside production first Validate MariaDB Operator and Valkey under your own deployment patterns, including failover behaviour, persistence, and configuration overrides. Do not assume parity with the bundled stack until the operational evidence is in place.
• Update offboarding rules for deprecated image sources Create a deprecation response that treats a retired image repository like any other lifecycle event. Remove trust in the old source, document the migration path, and ensure no production workload still depends on a non-maintained dependency.

Key takeaways

• Bitnami’s repository change turns a packaging decision into a dependency lifecycle problem for production Kubernetes users.
• The main risk is stale, unpatched images and unclear ownership, not merely a change in chart defaults.
• Teams should map, test, and govern replacement dependencies before they inherit unsupported infrastructure in production.

Key terms

• Helm Chart Dependency: A Helm chart dependency is an external component that the chart installs or references to make an application run. In Kubernetes, those dependencies can include databases, caches, and supporting services whose image sources, versioning, and upgrade path must be governed like any other production dependency.
• Legacy Image Repository: A legacy image repository is a container image source that remains accessible but no longer receives active fixes or security updates. Organisations can still pull from it, but they inherit stale-image risk and must decide whether to mirror, replace, or retire the dependency.
• Lifecycle Ownership: Lifecycle ownership is the assignment of accountable responsibility for maintaining, upgrading, and retiring a dependency over time. In identity-adjacent infrastructure, it includes provenance, patching, failover testing, and offboarding so that the service remains trustworthy after upstream changes.

What's in the full article

Passbolt's full blog post covers the operational detail this post intentionally leaves for the source:

• The exact Helm chart dependency changes Passbolt is planning for MariaDB and Redis-compatible services
• The migration path from Bitnami subcharts to MariaDB Operator and Valkey in an open-source stack
• The early-adoption options for teams that want to test their own database and cache components
• The rollout timeline and breaking-change considerations for existing Passbolt Helm users

👉 Passbolt’s full post covers the replacement stack, transition timing, and early-adopter options.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.