A continuation of the discussion from May 7 2026 on service bindings in LabKit/Fairway/Runway... From https://docs.google.com/document/d/14O9z9BDiXkIjwHOi63bT_mhIgghJD1zVazwrsn3ZySw/edit?tab=t.0#bookmark=id.vr9q2v6vaa2a >>> 2. Andrew Newdigate: Let's look into whether we could use ServiceBindings to bind what the operator produces (ie, secrets for password) and what the application requires, coupling the two together in a well-architected manner. 1. [https://servicebinding.io/](https://servicebinding.io/) 2. Go Libraries: [https://github.com/baijum/servicebinding](https://github.com/baijum/servicebinding) [https://github.com/nebhale/client-go](https://github.com/nebhale/client-go) 3. Big downside: custom operator, not native, CRDs required. >>> ## Introduction Part of the discussion focused on the [ServiceBinding.io framework](https://servicebinding.io/). The framework is not native to Kubernetes and would require customers to install the operator, CRDs etc in their clusters, which is not going to work for our use case, given the self-managed nature of our product. The reference implementation, the Red Hat Service Binding Operator, was also deprecated in February 2024, so the operator-led path is also a fading ecosystem. We can, however, adopt the spec's *interface contract* — the [`$SERVICE_BINDING_ROOT`](https://servicebinding.io/spec/core/1.1.0/) directory layout, default `/bindings`, with one file per key and a `type` entry identifying the service — without adopting the controller. The projection format is just files on a filesystem; what put them there is invisible to the application. This means our output is bit-for-bit compatible with the spec, and existing client libraries ([baijum/servicebinding](https://github.com/baijum/servicebinding), [nebhale/client-go](https://github.com/nebhale/client-go) work unchanged. In other words, we get the spec's interface contract without taking on the controller's operational footprint. Additional merics: debuggable with `kubectl exec -- ls /bindings/postgres`, zero CRDs to learn, failure mode is "file missing" rather than "controller didn't reconcile," and customers adopt it per-service rather than via a cluster-wide install. ## Requirements 1. The binding output should match the Service Binding spec's directory layout (`$SERVICE_BINDING_ROOT/<service>/<key>`). This avoids inventing our own spec and lets us rely on existing client libraries. 2. The binding should support live updates to upstream Secret/ConfigMap data without a pod restart, with changes visible to a watching application. 3. We should ship common bindings (e.g. CloudNativePG, Crunchy, Zalando) but allow customers to plug in their own. 4. We should support customer-managed Secrets/ConfigMaps for externally-managed resources, including ESO Generators (which produce short-lived IAM-scoped tokens via mechanisms like `aws rds generate-db-auth-token`). ## What this is not This is not a replacement for ESO, sealed-secrets, or any other secret-sourcing tool. It's the layer above them. The chart's contract is "give me a Secret with these keys (or these renamable keys)" — how the customer produces that Secret (operator-generated, ESO-synced, hand-rolled, sealed) is orthogonal. ```mermaid flowchart LR Z[Zalando<br/>postgres-operator] C[CloudNativePG<br/>cnpg.io] P[CrunchyData<br/>PGO] ZS["Secret: ...credentials...<br/>username, password<br/><i>(no host or port)</i>"] CS["Secret: gitlab-app<br/>username, password,<br/>host, port, dbname"] PS["Secret: gitlab-pguser-gitlab<br/>user, password,<br/>host, port, dbname"] PV["projected volume<br/>items[] rename + merge<br/>+ ConfigMap for type/provider<br/>and missing fields<br/><br/>/bindings/postgres/<br/>type, provider, host, port,<br/>database, username, password"] T[Theseus<br/>reads $SERVICE_BINDING_ROOT] Z --> ZS C --> CS P --> PS ZS --> PV CS --> PV PS --> PV PV --> T classDef operator fill:#EEEDFE,stroke:#534AB7,color:#26215C classDef secret fill:#E1F5EE,stroke:#0F6E56,color:#04342C classDef binding fill:#FAEEDA,stroke:#854F0B,color:#412402 classDef workload fill:#FAECE7,stroke:#993C1D,color:#4A1B0C class Z,C,P operator class ZS,CS,PS secret class PV binding class T workload ``` The projected volume normalises operator-specific key names (`user`, `dbname`, etc.) to the spec's expected names (`username`, `database`). ## Proposed Solution: Projected Volumes We rely on [projected volumes](https://kubernetes.io/docs/concepts/storage/projected-volumes/) to generate the `/bindings/*` configurations. These create the indirection required to give customers flexibility, allowing them to compose different solutions for resource connectivity and dependency resolution. ### Worked Example The service binding spec wants: ``` /bindings/postgres/ type → "postgresql" provider → "..." (optional) host → ... port → ... database → ... username → ... password → ... ``` So you need (a) per-key renaming, (b) values the operator doesn't provide (like `type: postgresql` literally), and (c) sometimes synthesized values (like Zalando's host). #### Customer is using CloudNativePG CNPG provides almost everything the spec wants out of the box; the chart only adds `type` and `provider`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: postgres-binding-meta data: type: postgresql provider: cnpg --- volumes: - name: postgres-binding projected: sources: - configMap: name: postgres-binding-meta - secret: name: gitlab-app # CNPG's secret items: - key: username path: username - key: password path: password - key: host path: host - key: port path: port - key: dbname path: database # rename: dbname → database ``` #### Customer is using CrunchyData ```yaml apiVersion: v1 kind: ConfigMap metadata: name: postgres-binding-meta data: type: postgresql provider: crunchydata --- volumes: - name: postgres-binding projected: sources: - configMap: name: postgres-binding-meta - secret: name: gitlab-cluster-pguser-gitlab # PGO's secret items: - key: user path: username # rename: user → username - key: password path: password - key: host path: host - key: port path: port - key: dbname path: database # rename: dbname → database volumeMounts: - name: postgres-binding mountPath: /bindings/postgres readOnly: true env: - name: SERVICE_BINDING_ROOT value: /bindings ``` #### Customer is using Zalando The Zalando operator produces a Secret without `host`, `port`, or `database`. The chart (or the customer) supplies these via the ConfigMap: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: postgres-binding-meta data: type: postgresql provider: zalando host: gitlab-pg.gitlab.svc.cluster.local # rendered from chart values port: "5432" database: gitlab --- volumes: - name: postgres-binding projected: sources: - configMap: name: postgres-binding-meta # supplies host/port/database/type/provider - secret: name: gitlab.gitlab-pg.credentials.postgresql.acid.zalan.do items: - key: username path: username - key: password path: password ``` Note: the `items:` filter acts as the binding's allowlist. Anything not explicitly listed never reaches the application. Even when no rename is happening, listing keys explicitly prevents future operator changes (a new field added to the Secret) from silently leaking into `/bindings/postgres/`. ## Constraints worth being aware of **No value transformation, only projection.** Projected volumes can rename and merge keys but cannot parse a connection string into parts, decode JSON, or strip a prefix. If a future operator only exposes `connection-string: postgres://user:pass@host:5432/db`, this design needs an escape hatch — ESO with templating, an init container, or a small reshaper. None of the operators we plan to ship for hit this case, but the design assumes it. **Live update gotchas.** Projected volumes do support live updates (satisfying requirement 2), with two caveats: - `subPath` mounts do **not** receive updates. The chart helper must never use `subPath` for binding mounts. - Propagation happens on kubelet's sync period (typically up to ~60s, configurable via `--sync-frequency`), not instantaneously. Applications needing sub-second rotation responsiveness need to know this. **Metadata ConfigMap vs Secret.** The examples above put non-sensitive metadata (`type`, `provider`, sometimes `host`/`port`/`database`) in a ConfigMap. In regulated or multi-tenant environments, backend identity may be in-scope sensitive data and customers will want this in a Secret instead. The projected-volume mechanism is identical for both, so this becomes a chart-level toggle (default ConfigMap, opt-in to Secret) rather than a design change. ## Binding Abstraction In each case, the client application only needs to read `/bindings/postgres` and the information is presented in a consistent manner, with indirection providing flexibility to support various operators, ESOs, or manually maintained secrets. cc @chsanders @WarheadsSE @octo @e_forbes