egress: add credential provider which reads from k8s secret by yufan-su · Pull Request #1335 · agent-substrate/substrate

yufan-su · 2026-08-31T16:56:37Z

First of a two-PR stack for atenet egress credential injection change. This PR adds the credential provider; the follow-up adds the egress injector that calls it.

What this adds

A credprovider gRPC service implementing the CredentialProvider.RequestSecret plugin API (pkg/proto/credproviderpb), backed by Kubernetes Secrets. It resolves substrate-secret://kubernetes.io/<provider>/<namespace>/<secret>[/<key>] URIs to a Secret value — brokering a read it's authorized to perform rather than persisting the secret itself.

Authorization

Default-deny atespace→namespace mapping (internal/proto/nsauthzpb); an atespace can only resolve secrets from its permitted namespaces.
The atespace is derived from the attested actor SPIFFE identity (internal/actorspiffe, shared with the injector in the next PR).
mTLS with optional client-CA verification for callers.

Included

cmd/credprovider (service + kubeprovider backend)
pkg/proto/credproviderpb (plugin API), internal/proto/nsauthzpb (authz mapping), internal/actorspiffe (SPIFFE parser)
Deploy manifest + namespace-policy / sample-secret fixtures

Eitan Yarmush (EItanya) · 2026-08-31T18:58:26Z

I think this PR is honestly a bit noisy. There's both the credential provider, and the implementation of yet another extproc server which uses it. Can we instead review the credential provider in isolation, especially given that there are still open questions in the doc, and then we can tackle the thing which calls it?

Doc since it's not linked anywhere: https://docs.google.com/document/d/1-zQKvu-oYJlva_kwL3xbAOaFoJJaqO0qEqmqRlt1r0c/edit?resourcekey=0-TDrWohfRuYolcXYO-QPVTQ&tab=t.0#heading=h.rx0okwgtp5yu

Lior Lieberman (LiorLieberman)

We discussed offline but for posterity, Eitan Yarmush (@EItanya) 's idea to split the pr sounds good.

yufan-su · 2026-09-01T04:07:58Z

Split into two PRs #1335 and #1360 and this one only contains the credential provider change.

Lior Lieberman (LiorLieberman)

Thanks yufan-su !

Lior Lieberman (LiorLieberman) · 2026-09-01T05:29:09Z

+// ProviderClass is the substrate-secret:// URI host this backend serves.
+const ProviderClass = "kubernetes.io"


nit: we removed "providerClass" concept from the doc and its now only provider name. the name is kubernetes.io

Lior Lieberman (LiorLieberman) · 2026-09-01T05:31:45Z

+// loads from a textproto file at startup. It maps each atespace to the
+// Kubernetes namespaces whose Secrets that atespace may resolve. Enforcement is
+// default-deny: an atespace absent from this file can resolve nothing. This is a
+// POC stand-in for a future authorization API.


comment is very verbose, can we remove things that are POC related and make it shorter?

I agree with Lior Lieberman (@LiorLieberman) here, it's not clear we really need these proto types at all?

Doubly so given that this never goes over the wire, it could just be golang directly

Lior Lieberman (LiorLieberman) · 2026-09-01T05:32:41Z

+# nothing. credprovider loads it once at startup, so editing this ConfigMap
+# requires restarting the credprovider Deployment to take effect.


should we add a TODO to make it dynamically reload?

Eitan Yarmush (EItanya) · 2026-09-01T13:55:42Z

+  namespace: ate-system
+---
+apiVersion: apps/v1
+kind: Deployment


Creating YET another deployment for this feels like it spreads our deployment footprint out quite a bit. What do you think about running this as a sidecar for the egress policy, or from the control-plane somehow? I'm worried about:

Latency

deployment footprint

I think we need to see if we consider this more of an example vs something that a lot of users will use.

Key things that would make some of the decisions:

Would this be enabled by default (with opt-out)

How we document the positioning of this (it's for demos vs it's for prod)

Eitan Yarmush (EItanya) · 2026-09-01T13:55:59Z

+// loads from a textproto file at startup. It maps each atespace to the
+// Kubernetes namespaces whose Secrets that atespace may resolve. Enforcement is
+// default-deny: an atespace absent from this file can resolve nothing. This is a
+// POC stand-in for a future authorization API.


I agree with Lior Lieberman (@LiorLieberman) here, it's not clear we really need these proto types at all?

Eitan Yarmush (EItanya) · 2026-09-01T13:56:47Z

+  // The attested actor identity on whose behalf the secret is fetched. Today
+  // this is the actor's SPIFFE URI as verified by the egress gateway; a
+  // verifiable Actor JWT is the intended future form.
+  string actor_identity = 1;


Is this secure? Wouldn't we need the actual actor identity document?

Eitan Yarmush (EItanya) · 2026-09-01T13:58:34Z

+    # atespace "team-a" may resolve secrets in namespace "ns1" (matches the
+    # sample policy's substrate-secret://kubernetes.io/team-secrets/ns1/example-api).
+    policy {
+      atespace: "team-a"
+      allowed_namespaces: "ns1"
+    }


Has this API been discussed at all? This seems like an important piece we need to come to agreement on which was not in the doc Bowei Du (@bowei) Lior Lieberman (@LiorLieberman)

It's somewhat separate than the doc as this is specific to cred provider implementation.

I was thinking for this example, we do something very simple like a static YAML map of atespace(s) to k8s namespaces.

Nit: probably shouldn't use textproto, this is not a very popular format (outside of Google)

Eitan Yarmush (EItanya) · 2026-09-01T13:58:59Z

+// loads from a textproto file at startup. It maps each atespace to the
+// Kubernetes namespaces whose Secrets that atespace may resolve. Enforcement is
+// default-deny: an atespace absent from this file can resolve nothing. This is a
+// POC stand-in for a future authorization API.


Doubly so given that this never goes over the wire, it could just be golang directly

Eitan Yarmush (EItanya) · 2026-09-01T13:59:22Z

+
+// TrustDomain is the SPIFFE host an actor identity URI carries, matching the URI
+// minted in cmd/ateapi/internal/actoridentity.
+const TrustDomain = "substrate-actor.local"


This relates to my comment about the actual actor credential, I think this is a code smell from that

Eitan Yarmush (EItanya) · 2026-09-01T13:59:38Z

+	metricsAddr  = pflag.String("metrics-address", ":9090", "Prometheus/health HTTP listen address")
+	serverBundle = pflag.String("server-cred-bundle", "", "credential bundle (PEM key+chain) presented for serving TLS; empty serves plaintext (dev only)")
+	clientCAFile = pflag.String("client-ca-file", "", "CA bundle that caller (injector) client certificates must chain to; empty accepts any client when TLS is on")
+	defaultKey   = pflag.String("default-secret-key", "", "Secret data key used when a credential URI omits one; empty requires a single-key Secret")


I don't think this is a good idea

yufan-su requested review from Lior Lieberman (LiorLieberman) and Bowei Du (bowei) August 31, 2026 16:56

Lior Lieberman (LiorLieberman) reviewed Sep 1, 2026

View reviewed changes

Comment thread manifests/egress-credential-injection/README.md Outdated

yufan-su force-pushed the cred-provider-plugin branch from 7e2e606 to 02a01c3 Compare September 1, 2026 03:35

add credential provider

d2731aa

yufan-su force-pushed the cred-provider-plugin branch from 02a01c3 to d2731aa Compare September 1, 2026 03:59

yufan-su changed the title ~~egress: add credential injector and credential provider~~ egress: add credential provider which reads from k8s secret Sep 1, 2026

yufan-su mentioned this pull request Sep 1, 2026

egress: add credential injector #1360

Open

Lior Lieberman (LiorLieberman) reviewed Sep 1, 2026

View reviewed changes

Lior Lieberman (LiorLieberman) requested a review from Eitan Yarmush (EItanya) September 1, 2026 05:51

Eitan Yarmush (EItanya) requested changes Sep 1, 2026

View reviewed changes

		// ProviderClass is the substrate-secret:// URI host this backend serves.
		const ProviderClass = "kubernetes.io"

		# nothing. credprovider loads it once at startup, so editing this ConfigMap
		# requires restarting the credprovider Deployment to take effect.

Uh oh!

Conversation

yufan-su commented Aug 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What this adds

Authorization

Included

Uh oh!

Eitan Yarmush (EItanya) commented Aug 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Lior Lieberman (LiorLieberman) left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

yufan-su commented Sep 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Lior Lieberman (LiorLieberman) left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

yufan-su commented Aug 31, 2026 •

edited

Loading

Eitan Yarmush (EItanya) commented Aug 31, 2026 •

edited

Loading

yufan-su commented Sep 1, 2026 •

edited

Loading