Source cluster token and CA from a Kubernetes Secret ref#36
Merged
Conversation
The fleet registry kept each cluster's bearer token (and CA) inline as
plaintext, and the StateStore persisted it as-is. Let a registry record
instead carry tokenSecretRef / caSecretRef ({name, namespace, key?}) and
resolve the secret material only at connection time.
resolve_secrets(record, reader) reads each ref through an injectable
secret_reader, base64-decodes the value, and fills token/ca on a copy of
the record. The original is never mutated, so plaintext is never written
back into the registry. Inline token/ca keeps working for back-compat;
an explicit ref wins when both are present.
KubeCRGateway gains a secret_reader seam (defaults to reading Secrets via
elpio.k8s.get_object) and resolves the record in _client before building
the dynamic client. The management API accepts the refs on ClusterCreate;
they carry no secret material so they round-trip in responses, while the
existing redaction still strips token/ca and no resolved token is ever
returned.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The fleet registry held each cluster's bearer
token(andca) inline as plaintext, and theStateStorepersisted it verbatim. This adds a seam so the sensitive fields can be sourced from a Kubernetes Secret instead.A registry record may now carry
tokenSecretRef/caSecretRef({name, namespace, key?}) in place of an inlinetoken/ca. The newresolve_secrets(record, reader)insrc/elpio/api/gateway.pyreads each ref through an injectablesecret_reader, base64-decodes the value, and fillstoken/caon a copy of the record. The input record is never mutated, so plaintext is never persisted back into the registry.Details
resolve_secretsis pure and testable: thesecret_reader(Callable[[name, namespace, key], str]) is injected, so unit tests pass a fake reader and never touch a cluster. The default reader reads Secrets viaelpio.k8s.get_object.KubeCRGatewaygains asecret_readerparam and resolves the record in_clientbefore building the dynamic client. The existingclient_factoryseam is unchanged.token/cakeeps working (back-compat). When both an inline value and a matching ref are present, the explicit ref wins.ClusterCreate. Secret refs carry no secret material, so they round-trip in responses; the existing redaction still stripstoken/ca, and no resolved plaintext token is ever returned.src/elpio/k8s.pysignatures are untouched.Tests
tests/unit/test_gateway.py: ref resolves to a working token record; customcakey; inline token still works with no reader; resolver does not mutate or persist plaintext (gateway resolves at connect time, registry keeps only the ref); explicit ref overrides a stale inline token.tests/unit/test_api.py: atokenSecretRefsurvives in API responses while carrying no plaintext.160 unit tests pass; ruff clean.