ILM Operator: Cryptographic Asset Management, Simplified

TL;DR: Certificates, keys, and secrets need lifecycle management — and the platform that provides it should not become its own operations project. The updated ILM operator reduces running ILM to two declared Kubernetes resources, Platform and Connector. Your effort goes into governing cryptographic assets, not maintaining infrastructure.

Look at where your cryptographic assets live today. Certificates terminate TLS in every namespace. Meanwhile, keys sit in HSMs and cloud key stores. Secrets spread across HashiCorp Vault and Kubernetes. Every one of them has an expiry, an owner, and a policy it should follow. Because certificate expiration still causes outages in 2026, most teams already know that spreadsheets and calendar reminders do not scale.

Trust lifecycle management is the answer to that sprawl. ILM, the open-source identity lifecycle management platform, exists to create, sync, rotate, and revoke those artifacts under policy. In addition, it gives you an inventory you can audit and automation you can verify. However, there has always been a quiet prerequisite: someone has to deploy and operate ILM itself. For many teams, that operational cost decided whether governed cryptographic assets were worth pursuing at all. The recent update to the ILM operator takes aim at exactly that cost.

The Real Product Is Governed Cryptographic Assets

It is worth being precise about what you actually want from a platform like ILM. To begin with, you want to know every certificate, key, and secret you own, and what state it is in. You also want rotation to happen on schedule, not when an outage forces it. Likewise, revocation must be fast when trust is lost. Finally, you want evidence of all of this that survives an audit. That is the product. The deployment underneath it is overhead.

Yet the overhead has traditionally been substantial. Running ILM on Kubernetes meant maintaining a values file that describes the full stack, scheduling upgrades, verifying component compatibility, and watching rollouts. The Helm chart installs ILM well — but it steps away the moment the install finishes. Every hour spent on that work is an hour not spent governing the assets the platform was bought to govern. The right amount of time to spend on deployment mechanics is as little as possible.

What the ILM Operator Takes Off Your Plate

The Kubernetes operator pattern moves operational knowledge out of runbooks and into software. You declare the state you want, and a controller works continuously to keep the cluster matching it. With the ILM operator, that declaration is a single Platform resource. It states which version, which database, which message broker, which identity provider, and how the platform is exposed. The operator builds ILM from it and never stops reconciling. If something drifts, it converges back. If you change the declaration, the operator rolls the change out in the right order.

The stateful dependencies stay deliberately flexible. PostgreSQL, RabbitMQ, and Keycloak can each be external, so ILM points at infrastructure you already run. Alternatively, they can be managed: the operator delegates provisioning to the established operator for each technology rather than re-templating those systems itself. In practice, the quickstart path is “everything managed” — a working ILM on a fresh cluster, with no secrets to create up front.

Your time goes to…	Helm chart deployment	Operator-managed deployment
Standing up ILM	Composing a values file that covers the full stack	Declaring one Platform resource
Upgrades	Running the upgrade and verifying compatibility yourself	Editing the version to a tested bundle
Configuration drift	Finding and fixing it manually	Nothing — reconciliation converges it back
Credential rotation	Redeploying affected components yourself	Nothing — referenced Secrets are watched
Extending coverage	Configuring a subchart and upgrading the release	Declaring one Connector resource

Of course, both models deploy the same platform, and the Helm chart remains a familiar starting point. The difference is where your hours go afterwards. That shift is what makes cryptographic asset management simpler in practice: the platform doing the managing now needs far less management itself.

Reach Every Place Your Trust Artifacts Live

A lifecycle platform is only as useful as its reach. ILM touches your estate through connectors. They reach certificate authorities such as Microsoft AD CS and EJBCA, HashiCorp Vault for secrets, and discovery and compliance providers. Those connectors define how much of your cryptographic estate is actually governed. The same coverage question drives building a comprehensive cryptographic asset inventory. Similarly, it is why lifecycle governance must include secrets, not just certificates.

With the operator, each connector becomes its own Connector resource, deployed and configured independently of the platform. Consequently, extending governance to a new corner of your estate — another CA, another vault, another discovery source — is a declaration, not a deployment project. A connector can even register itself with ILM. The familiar approval flow stays intact: the connector waits for approval until an administrator accepts it.

The Discipline ILM Applies to Your Assets, Applied to ILM

ILM’s whole argument is that trust artifacts should be governed by automation, not by heroics. Consequently, the operator extends that argument to the platform itself, and it shows most clearly in the day-2 details.

• Upgrades become a one-line change. The version field selects a tested bundle that pins every component image — combinations validated together, not assembled by hand.
• Nothing changes behind your back. A platform pins its version when it is created. Upgrading the operator never silently upgrades a running platform, and a major version change to managed infrastructure waits for your explicit acknowledgment.
• Rotation propagates. When a referenced Secret changes — say a database credential rotates — the operator notices and redeploys the affected components. Credentials never live in the resource itself; only references to Kubernetes Secrets do.
• Status tells the truth. The platform reports its phase and conditions from measured readiness — what is actually serving — rather than from assumptions about what should be.
• Deletion is safe by default. Deleting a Platform resource keeps the data of managed infrastructure intact unless you explicitly choose otherwise.

A platform that automates the lifecycle of trust should itself be lifecycle-automated.

In practice, this is what moving PKI from ad-hoc to governed operations looks like at the deployment level. As a result, the platform arrives documented, repeatable, and continuously enforced — with default-on network policies and hardened workloads out of the box.

Built in the Open — and Early Enough to Shape

Everything described above is public. The operator lives at github.com/OmniTrustILM/operator under the MIT license. Its documentation ships alongside it: a quickstart, a configuration reference, design documents, and more than two dozen sample resources. For teams already running the Helm chart, there is a documented migration path. Moreover, a converter tool translates an existing values file about 90% of the way to a Platform resource. It flags the remainder for review.

Honesty matters here: this is early software. The Platform and Connector resources recently landed in the repository, and the operator is at an alpha level of maturity. For the community, that timing is the opportunity. Indeed, the decisions that will shape the operator are being made now. Which deployment scenarios should the samples cover? What must a migration handle? Which edge configurations matter? Feedback filed today has more leverage than feedback filed after the interfaces settle.

---

Try it on a test cluster: head to github.com/OmniTrustILM/operator, follow the quickstart, and declare your first Platform. Then tell us what your estate needs governed — open an issue with your scenario, your migration questions, or the connector you want to run next. This is the stage where your input shapes the operator most.