[Sandbox] RollingZero (currently ILM)

### Project summary

RollingZero — currently published as ILM — is a Kubernetes-native platform for machine identity and trust lifecycle management: certificates, cryptographic keys, secrets, and digital signatures across heterogeneous trust infrastructure, extended through a public connector contract.

### Project description

**Naming.** This project is published today as **ILM**, and all repositories, documentation, and policies linked in this application carry that name. ILM is a registered brand of OmniTrust Security and is being retained for its commercial line. On acceptance, the contributed project is renamed and rebranded to **RollingZero** — a neutral name to be assigned to the Linux Foundation — so that no confusion with the OmniTrust ILM brand can arise. "RollingZero" and "ILM" in this application refer to the same codebase at two points in time.

Machine identity is the dominant identity class in cloud native infrastructure and the least consistently managed. A typical enterprise runs certificates from several CAs, keys in several stores, and secrets in several vaults, with no shared inventory, no common policy surface, and no single audit trail. Although Kubernetes-native tooling might solve this inside the cluster, almost nothing solves it across the boundary between the cluster and the enterprise PKI that surrounds it.

RollingZero is that layer: deployed by Helm chart or by its Kubernetes operator, abstracting heterogeneous trust infrastructure behind a small set of stable objects.

- **RA Profile** — certificate lifecycle configuration, independent of the issuing CA technology
- **Token Profile** — cryptographic key management and operations (generation, signing, encryption), independent of the backing key store
- **Signing Profile** — configuration for digital signing and timestamping: signing scheme, workflow, signature family, and time-quality requirements
- **Vault Profile** — secrets with versioning, cross-vault synchronization, approval workflows, compliance evaluation
- **Compliance Profile** — declarative policy evaluated continuously across the inventory

Everything touching a specific technology sits behind a **connector**: a documented, public REST contract any third party implements without changing the core. The same abstraction serves every domain — an authority connector issues certificates, a cryptography connector performs key operations, a discovery connector finds them — so the platform extends to new trust technologies without core changes. Connectors in the contributed scope cover EJBCA, Microsoft ADCS, HashiCorp Vault PKI, Certificate Transparency logs, network discovery, Java keystores, software key stores, X.509 compliance evaluation, and email and webhook notification.

Capabilities:

- **Certificate lifecycle** — request, issue, renew, rekey, revoke; ACME, SCEP (including Microsoft Intune), CMP
- **Discovery and inventory** — continuous discovery across networks, keystores, and CT logs into one inventory of certificates and keys with owners, groups, and entities
- **Cryptographic key management** — key generation, signing, and encryption operations through the Token Profile abstraction, with a software key-store provider included and the provider interface open for other implementations
- **Digital signing and timestamping** — Signing Profiles with managed and delegated signing schemes; content-signing, raw-signing, and timestamping workflows; a signing engine with signing-certificate validation and state management; durable signing records with configurable immediate, deferred-durable, and best-effort persistence strategies for audit
- **Secrets management** — versioned secrets, approval workflows, cross-vault synchronization
- **Post-quantum algorithms** — ML-DSA, SLH-DSA, ML-KEM, FALCON (FN-DSA) in the core
- **Policy and authorization** — every access decision evaluated by Open Policy Agent against versioned Rego bundles; OIDC via IdP
- **Observability** — native OpenTelemetry metrics, traces, logs

For operators and contributors: a Kubernetes operator, a cert-manager external issuer, a CLI, a Go SDK, an MCP server for agent-driven operation, an automated end-to-end and integration test framework, and a Docker Compose development environment.

In continuous public development since 2021 (also as CZERTAINLY), deployed in production at public-sector, financial-services organizations, trust service providers, telecommunications, and industrial operations.

### Project vs Reference Architecture/Implementation

- [x] This is a reusable open source project designed for broad adoption, not a reference architecture, reference implementation, or demonstration of patterns

### Org repo URL (provide if all repos under the org are in scope of the application)

N/A — not all repositories in https://github.com/OmniTrustILM are in scope; the 36 contributed repositories are enumerated in the next field.

### Project repo URL in scope of application

https://github.com/OmniTrustILM/ilm

### Additional repos in scope of the application

The 36 contributed repositories. Repositories in the `OmniTrustILM` organization not listed here are out of scope.

**Core platform**
https://github.com/OmniTrustILM/core
https://github.com/OmniTrustILM/auth
https://github.com/OmniTrustILM/auth-opa-policies
https://github.com/OmniTrustILM/scheduler
https://github.com/OmniTrustILM/interfaces
https://github.com/OmniTrustILM/utils-service
https://github.com/OmniTrustILM/dependencies

**User interface**
https://github.com/OmniTrustILM/fe-administrator

**Connectors and providers**
https://github.com/OmniTrustILM/common-credential-provider
https://github.com/OmniTrustILM/ejbca-ng-connector
https://github.com/OmniTrustILM/pyadcs-connector
https://github.com/OmniTrustILM/hashicorp-vault-connector
https://github.com/OmniTrustILM/x509-compliance-provider
https://github.com/OmniTrustILM/ip-discovery-provider
https://github.com/OmniTrustILM/ct-logs-discovery-provider
https://github.com/OmniTrustILM/cryptosense-discovery-provider
https://github.com/OmniTrustILM/keystore-entity-provider
https://github.com/OmniTrustILM/software-cryptography-provider
https://github.com/OmniTrustILM/email-notification-provider
https://github.com/OmniTrustILM/webhook-notification-provider

**Kubernetes**
https://github.com/OmniTrustILM/cert-manager-issuer
https://github.com/OmniTrustILM/operator
https://github.com/OmniTrustILM/cli

**Developer ecosystem**
https://github.com/OmniTrustILM/go-sdk
https://github.com/OmniTrustILM/automated-testing-framework
https://github.com/OmniTrustILM/development-environment

**Deployment**
https://github.com/OmniTrustILM/helm-charts
https://github.com/OmniTrustILM/keycloak-optimized
https://github.com/OmniTrustILM/keycloak-theme
https://github.com/OmniTrustILM/provisioning-rabbitmq
https://github.com/OmniTrustILM/mcp-server

**Documentation**
https://github.com/OmniTrustILM/documentation
https://github.com/OmniTrustILM/interface-documentation

**Project governance**
https://github.com/OmniTrustILM/ilm
https://github.com/OmniTrustILM/.github
https://github.com/OmniTrustILM/.allstar

### Website URL

https://docs.otilm.com

### Roadmap

https://github.com/orgs/OmniTrustILM/projects/5/views/13

### Roadmap context

1. **Kubernetes-native operation.** Operator to a stable CRD versioning strategy, so profiles and policies are declared as Kubernetes resources and reconciled rather than configured through the REST API alone; `kubectl` plugin for routine operations.
2. **Connector ecosystem.** The connector contract is the extension point. Work here targets third-party connector development: example connectors, contract test suites in the e2e framework, documentation written for people who have never seen the codebase. Success is measured in connectors written by non-maintainers.
3. **Community and neutrality.** The governance model is published and the first maintainers from outside the founding organization are seated; the work ahead is widening that beyond three organizations, alongside CNCF onboarding.

A 3.0 release with breaking API contract changes is planned; the community will be consulted on the migration path before it lands.

### Contributing guide

https://github.com/OmniTrustILM/.github/blob/main/CONTRIBUTING.md

### Code of Conduct (CoC)

https://github.com/OmniTrustILM/.github/blob/main/CODE_OF_CONDUCT.md

### Adopters

https://github.com/OmniTrustILM/ilm/blob/main/ADOPTERS.md

### Maintainers file

https://github.com/OmniTrustILM/ilm/blob/main/MAINTAINERS.md

### Security policy file

https://github.com/OmniTrustILM/.github/blob/main/SECURITY.md

### Standard or specification?

No. RollingZero is a platform implementation, not a standard or specification. It implements established standards rather than defining them: RFC 5280 (X.509), RFC 8555 (ACME), RFC 8894 (SCEP) and RFC 4210 (CMP).

The project does define one public integration contract: a documented REST interface that third parties implement to add support for new certificate authority, discovery, compliance, or key-store technologies. It is a project extension contract maintained in the open, not a standards-body deliverable, and the project does not seek to standardize it through an external body.

### Business product or service to project separation

RollingZero is contributed by OmniTrust Security LLC, which also offers a commercial product, OmniTrust ILM Enterprise, built on the same codebase.

**Contributed — 36 capabilities.** The core platform (certificate lifecycle, discovery, inventory, authorities, tokens, secrets, and the signing subsystem — Signing Profiles and versioning, signing schemes and workflows, the signing engine, durable signing records, TSP profiles and time-quality evaluation, and the signature-formatting connector interfaces); authentication and OPA-based access control; scheduler; interface and provider definitions; common dependencies; the umbrella repository; certificate and key utilities; the administrative UI, dashboards and reporting; ten connectors and providers (EJBCA NG, Microsoft ADCS certificate management, HashiCorp Vault PKI, X.509 compliance evaluation, network discovery, Certificate Transparency log discovery, Cryptosense Analyzer ingestion, Java keystore entity management, software key-store cryptography, common credential provider); email and webhook notification; the cert-manager external issuer; the Kubernetes operator; Helm charts and Kubernetes installation tooling; optimized Keycloak image and theme; RabbitMQ provisioning; the CLI; the Go SDK; the MCP server; the end-to-end and integration test framework; the Docker Compose development environment; all platform, contributor, and API documentation; and the project's contribution workflows, templates, and OpenSSF Allstar security-policy configuration.

This is a standalone, production-capable platform. It installs and operates with no commercial component, no license key, and no dependency on any OmniTrust-operated service.

**Retained**, offered as OmniTrust ILM Enterprise: connectors and providers for specific commercial or proprietary technologies — additional certificate-authority integrations, hardware-backed key operations, and signature and time-stamp formatting — together with cryptographic bill-of-materials tooling and OmniTrust's own appliance, SaaS and operational tooling. Each retained connector implements the same public interfaces the contributed connectors do.

**The test we apply.** Certificate lifecycle, discovery and inventory, key management, secrets, compliance evaluation and signing all run on the contributed platform alone, with no commercial component and no licence key. Where a capability depends on a technology-specific connector — a particular certificate authority, a hardware key store, a document signature profile — that connector may be contributed, retained, or written by anyone against the same public interface.

**How the line is drawn.** The line is architectural: the contributed core owns the domain model, the orchestration, the workflow and state machinery, the audit trail, and the connector contracts; connectors implementing specific technologies may be contributed or retained. Certificate issuance is the clearest illustration: the EJBCA, Microsoft ADCS and HashiCorp Vault PKI connectors are contributed, and connectors for further authorities are written against the same public contract by us or by anyone else.

**The boundary is a starting point, not a wall.** Retained components may be contributed later, and the community is free to build open implementations against the same public interfaces; we would welcome both.

**Naming.** OmniTrust retains the OmniTrust and ILM marks. The contributed project is renamed RollingZero at onboarding precisely so that the two are never confused.

**Governance.** OmniTrust does not seek control beyond the influence its contributions earn. Maintainership already extends beyond OmniTrust: of twelve maintainers, two are from Cloudfield and Keenethics, holding review authority over the core platform and the user interface respectively. We regard multi-organization maintainership as a precondition for the project's health and are continuing to broaden it.

### Why CNCF?

Machine identity management is infrastructure no single vendor should own. It sits on the trust boundary: software deciding which workloads get credentials must be auditable and forkable without reference to a commercial relationship.

- **Neutrality is a requirement of the category, not a benefit.** Enterprise PKI adopters are correctly wary of lock-in at the trust layer. Foundation ownership removes the most common objection to adopting an open platform here.
- **The gap is adjacent to CNCF's existing work.** CNCF hosts the in-cluster certificate controller (cert-manager) and workload identity (SPIFFE/SPIRE). Neither addresses the enterprise PKI estate those systems connect to. RollingZero is that connective layer and ships a cert-manager issuer to prove it.
- **Post-quantum readiness is a cross-ecosystem problem.** Every project with a TLS dependency will need a certificate path handling ML-DSA, ML-KEM, and SLH-DSA end to end.
- **We want the community around the governance.** `GOVERNANCE.md` documents a contribution-based path to maintainership, appointment and removal by two-thirds vote, and an inactivity policy; `MAINTAINERS.md` names twelve maintainers, two of them employed outside OmniTrust. Sandbox, and the TOC's Contributor Strategy and Advocacy subproject, are where breadth beyond three organizations gets built.

Broadening the contributor base beyond the three organizations represented today is our principal obligation at Sandbox.

### Benefit to the landscape

The landscape covers certificate automation inside Kubernetes thoroughly and machine identity outside it barely at all. Between the cluster edge and the certificate authority sits an unrepresented layer: CA abstraction, discovery across a heterogeneous estate, and compliance policy over infrastructure only partly cloud native.

1. **A vendor-neutral trust-infrastructure abstraction.** One stable connector contract decoupling workloads from the specific PKI, key-store, and signing products an enterprise happens to own — the decoupling CSI and CRI achieved for storage and runtimes. It is not certificate-specific: the same contract carries certificate authorities, cryptographic providers and signature formatting. Our ambition for this contract is that it becomes a common open interface for managing cryptographic assets: something other projects and vendors implement against, so that operators are not locked to any single management plane. That is earned through adoption, not declared, and open governance is the precondition.
2. **A bridge to regulated PKI.** eIDAS and ETSI alignment lets cloud native platforms interoperate with regulated European trust infrastructure, today a proprietary-appliance market.
3. **Post-quantum algorithms in a production certificate path.** ML-DSA, SLH-DSA, ML-KEM in the core, giving the ecosystem somewhere to exercise PQ certificate handling end to end.
4. **An extension model built for other people.** Public connector and provider contracts, Go SDK, CLI, MCP server, contract-testing framework — the project is designed to grow through contributions its maintainers did not write.

### Cloud native 'fit'

- **Containerized microservices.** Core, auth, scheduler, connectors, and UI are independently deployable services over REST and a message broker.
- **Kubernetes-native deployment.** Helm charts and a Kubernetes operator are the two supported paths; the cert-manager external issuer makes the platform a first-class certificate source for in-cluster workloads.
- **Declarative configuration.** Profiles and policies are declarative objects, moving to CRDs for reconciliation.
- **Externalized policy.** All authorization delegated to Open Policy Agent with versioned Rego bundles; no policy embedded in application code.
- **Externalized identity.** OIDC via Keycloak or any OAuth2 enabled provider.
- **Observable by default.** Native OpenTelemetry metrics, traces, logs.
- **Stateless, horizontally scalable.** Role-based Spring profile deployments with KEDA autoscaling; state confined to PostgreSQL and the broker (AMQP 1.0, RabbitMQ or Azure Service Bus). Signing records use a transactional outbox with a drain scheduler and retention sweeper, so the audit trail survives pod loss and scale-down.
- **Cloud native supply chain.** GitHub Actions with unified reusable workflows, SLSA provenance and SBOM attestations on every published container image, OpenSSF Allstar policy enforcement, Trivy, CodeQL, Renovate, Dependabot.
- **Operable from terminal and agents.** CLI, Go SDK, MCP server.

Nothing in the contributed scope assumes a virtual machine, an appliance, or a vendor-operated service.

### Cloud native 'integration'

| Project | Status | Integration context |
|---|---|---|
| Kubernetes | Graduated | Primary deployment target. Operator (Kubebuilder v4), Helm charts, CRD-based configuration. |
| cert-manager | Graduated | Ships a cert-manager external issuer: in-cluster `Certificate` resources fulfilled by any enterprise CA behind a RollingZero connector. |
| Open Policy Agent | Graduated | Mandatory dependency. All access control evaluated by OPA against versioned Rego bundles. |
| OpenTelemetry | Graduated | Native instrumentation; OTLP export of metrics, traces, logs. |
| Keycloak | Incubating | OIDC provider; project ships an optimized image and theme. |
| Helm | Graduated | Official charts. |
| KEDA | Graduated | Event-driven autoscaling of worker roles. |
| Prometheus | Graduated | Metrics via OpenTelemetry export. |
| SPIFFE / SPIRE | Graduated | Complementary; no current integration. RollingZero manages the organizational CA hierarchy a SPIRE upstream authority can chain to. |

### Cloud native overlap

| Project | Status | Overlap context |
|---|---|---|
| cert-manager | Graduated | Both issue X.509 certificates. cert-manager is the Kubernetes controller for certificates consumed by cluster workloads; RollingZero ships an issuer that feeds it rather than replacing it. RollingZero manages machine identity across the enterprise estate — appliances, VMs, network devices, keystores with no Kubernetes representation — plus CA relationships, discovery, and compliance policy. cert-manager consumes trust; RollingZero manages the estate that produces it. |
| SPIFFE / SPIRE | Graduated | SPIRE issues short-lived attested workload identities from an attestation root. RollingZero manages long-lived organizational PKI with CA relationships, compliance obligations, and audit requirements. Complementary layers. |
| External Secrets Operator | Sandbox | ESO synchronizes secrets from external stores into Kubernetes. The Vault Profile manages secret lifecycle — versioning, approval workflow, cross-vault sync, compliance — as a first-class object of which Kubernetes is one consumer. |

No existing CNCF project covers enterprise-wide machine identity lifecycle across heterogeneous CA infrastructure.

### Similar projects

*Non-CNCF projects and products in the same category. (CNCF projects are covered under "Cloud native overlap" above.)*

| Project | Website | Similarity |
|---|---|---|
| EJBCA Community | https://www.ejbca.org | The established open-source certificate authority. EJBCA *is* a CA; RollingZero *manages* certificates across CAs including EJBCA, for which it ships a connector, and is frequently deployed in front of it. |
| Dogtag / FreeIPA | https://www.dogtagpki.org | Open-source CA and identity management. A CA rather than a cross-estate management layer; not Kubernetes-native. |
| Smallstep `step-ca` | https://smallstep.com/certificates | Open-source ACME/private CA with strong developer ergonomics. Overlaps on issuance; does not address multi-CA abstraction, cross-estate discovery, or compliance policy. |
| Venafi (CyberArk), Keyfactor, AppViewX | commercial | The commercial certificate lifecycle management category. Closed source. RollingZero is the open, self-hostable, Kubernetes-native alternative — the gap this contribution fills. |

### Landscape

No. The project is not yet listed on the Cloud Native Landscape; we submit an entry during onboarding.

### Insights

N/A — not yet on LFX Insights; completed during onboarding.

### Trademark and accounts

- [x] If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF

### IP policy

- [x] If the project is accepted, I agree the project will follow the CNCF IP Policy

### Will the project require a license exception?

N/A for the project's own license — every repository in scope is Apache-2.0.

### Does the project utilize any dependencies with licenses not on the allowlist or an approved exception?

Yes — fourteen dependencies, listed below. The project's own code is Apache-2.0 throughout. Nine arrive transitively through Spring Boot, Django and the Go toolchain as the ordinary platform libraries of those ecosystems; five are declared directly, each being the standard client or API library for the function it serves.

**They meet the Allowlist License Policy's conditions on use, and fall outside it on the licence identifier alone.** Every one is retrieved unmodified at build time from its upstream package repository and none is stored in, vendored into, or modified by the project's repositories — the consumption model condition 2(B) describes. All satisfy condition 3: each is at least four years old upstream and carries well over ten stars or forks. Only condition 1, the approved licence list, is not met.

- **EPL-2.0, or GPL-2.0 with the Classpath Exception** — `jakarta.annotation-api`, `jakarta.transaction-api`, `jakarta.jms-api`, `jakarta.mail-api`, `org.eclipse.angus:angus-mail`, `org.eclipse.angus:jakarta.mail`. Dual-licensed Jakarta EE API artifacts; the Classpath Exception exists precisely to permit linking.
- **EPL-1.0 or EPL-2.0, or LGPL-2.1** — `ch.qos.logback:logback-classic`, `ch.qos.logback:logback-core`. Dual-licensed; the default logging implementation of Spring Boot. The versions resolved across the estate span both EPL generations.
- **EPL-2.0** — `org.aspectj:aspectjweaver`, reached through Spring's AOP support.
- **LGPL-2.1-or-later** — `org.hibernate.orm:hibernate-core`, `org.hibernate.orm:hibernate-jpamodelgen`. Hibernate ORM is Apache-2.0 from 7.0, and that upgrade is staged in our dependency BOM, after which these two fall away.
- **LGPL-3.0-or-later with a linking exception** — `psycopg2-binary`, the standard PostgreSQL driver for Django.
- **MPL-2.0** — `github.com/hashicorp/vault-client-go`, HashiCorp's own client SDK for Vault. The register already carries MPL-2.0 blanket grants for `hashicorp/vault` and a dozen other HashiCorp libraries.
- **CC0-1.0** — `net.i2p.crypto:eddsa`, a public-domain dedication rather than a restrictive licence.

The Governing Board has approved most of these families — EPL-2.0, GPL-2.0 with Classpath Exception, LGPL-2.1 and MPL-2.0 — for Keycloak, a CNCF Java project with a comparable Jakarta EE and Hibernate dependency profile (exc-2024-10-22-002, cncf/foundation#817, scoped to that project). That grant does not reach LGPL-3.0-or-later or CC0-1.0.

**A further nine packages are already covered** by blanket grants for All CNCF Projects: `certifi` (exc-2026-02-18-002), `github.com/go-sql-driver/mysql` (exc-2019-03-11-020), `hashicorp/go-cleanhttp` (exc-2019-03-11-025), `hashicorp/go-retryablehttp` (exc-2021-07-19-001 and -002), `hashicorp/go-rootcerts` (exc-2023-06-27-016), `hashicorp/go-secure-stdlib` (exc-2023-06-27-006 and -017), `opencontainers/go-digest` (exc-2019-03-11-042), and the two Font Awesome Free packages used by the documentation website (exc-2019-03-11-009).

**No dependency is licensed under GPL or AGPL alone**, and nothing in the tree is AGPL.

We are happy for CNCF to run its SBOM generation tool against the 36 repositories enumerated above, and to supply our resolved dependency lists alongside it.

### Project "Domain Technical Review"

N/A.

### Application contact email(s)

roman.cinkais@omnitrust.com, caroline.yao@omnitrust.com

### Contributing or sponsoring entity signatory information

| Name | Address | Type | Signatory name and title | Email address |
|---|---|---|---|---|
| OmniTrust Security LLC | 20130 Lakeview Center Plaza, Suite 415, Ashburn, VA 20147, United States | Delaware Limited Liability Company | Thomas Heed, General Counsel | thomas.heed@omnitrust.com |

### CNCF contacts

Bob Killen, Marichris Espinosa (Linux Foundation).

### Additional information

**Naming — the contributed project is renamed at onboarding.** The project is published today as **ILM**; every repository, document, and policy linked in this application carries that name. **ILM is a registered brand of OmniTrust Security and is not being contributed** — it remains the brand of OmniTrust's commercial offering. To ensure there is no confusion between the two, the contributed project is renamed and rebranded to **RollingZero** during onboarding, as a neutral name to be assigned to the Linux Foundation, subject to LF trademark counsel approval; we will not proceed with a name counsel does not clear. Wherever this application says RollingZero, the linked material says ILM: same codebase, before and after the rename.

**Naming history.** The project was published as CZERTAINLY from 2021 and later renamed ILM. Commit history is continuous since 2021 and prior URLs redirect.

**Licensing.** Every in-scope repository is licensed under the Apache License 2.0. Third-party code bundled in a published artifact carries its own licence and notice file.

**Scope.** The 36 contributed repositories are enumerated above and are all public. The `OmniTrustILM` organization also holds repositories outside the contribution; the boundary is set out under "Business product or service to project separation." The project moves to its own neutral organization during onboarding.

**Community.** The project is built to be contributed to, not only consumed:

- Public issue trackers on every repository and GitHub Discussions at the organization level, actively used for release announcements and technical discussion
- A Docker Compose development environment — a contributor runs the full platform locally in one command
- An automated end-to-end and integration test framework, so contributions are verified against the whole system
- Public connector and provider contracts with example connectors, a Go SDK, a CLI, and an MCP server: the extension surface belongs to the community, not the maintainers
- A DCO sign-off enforced as a required status check on every repository in scope, so contribution provenance is unambiguous from the first pull request
- Contribution workflows, issue templates, and OpenSSF Allstar policy enforcement at organization level
Two public channels are open today: GitHub Discussions on the umbrella repository, and a Discord server. We would request a CNCF Slack channel at onboarding and migrate the Discord community to it.