[DONOTMERGE] WIP for SPIFFE Broker API - #1936
Draft
MikeZappa87 wants to merge 1 commit into
Draft
Conversation
istio-testing
added
the
do-not-merge/work-in-progress
|
😊 Welcome @MikeZappa87! This is either your first contribution to the Istio ztunnel repo, or it's been You can learn more about the Istio working groups, Code of Conduct, and contribution guidelines Thanks for contributing! Courtesy of your friendly welcome wagon. |
istio-testing
added
size/XXL
Contributor
|
Hi @MikeZappa87. Thanks for your PR. I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with Regular contributors should join the org to skip this step. Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
MikeZappa87
force-pushed
the
mzappa/brokerapi
branch
6 times, most recently
from
June 4, 2026 16:37
ba2fba7 to
d2fc21c
Compare
MikeZappa87
force-pushed
the
mzappa/brokerapi
branch
from
June 4, 2026 16:39
d2fc21c to
f5a71a3
Compare
Contributor
Author
|
spiffe/spiffe#340 has merged |
|
@MikeZappa87 any idea when this PR can merge so we can test the flow of ztunnel -> SPIRE ? I guess post this we also have the helm-charts PR merged..Hav been awaiting this integration for a while now ⌛👀 |
Contributor
|
PR needs rebase. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
istio-testing
added
the
needs-rebase
@yashwanth-l That PR is on hold until we have everything needed for Broker API in a SPIRE release. The one coming out this week will be incomplete so this chart PR will take a while. |
|
spiffe/helm-charts-hardened#876 Should have everything needed in the helm chart for this PR. |
|
The spire-0.30.0 chart has the local spire-agent broker support. So should be good to go. |
nddq
pushed a commit
to cilium/ztunnel
that referenced
this pull request
Aug 3, 2026
Ports istio#1936 (SPIFFE Broker API) onto this fork. The broker mints an SVID per workload rather than per SPIFFE identity, so it needs the cert cache keyed by workload. This fork already generalised the cache that way for the SPIRE delegated-identity provider, via CompositeId<K> plus a per-client key type resolved through FromCompositeId. The upstream PR introduced a parallel abstraction for the same axis -- CacheKey{Identity,Workload} and CertRequest -- which is isomorphic to CompositeId<RequestKey> but less general, since it fixes a single request shape for every provider. Rather than carry both, the broker client is implemented against the existing CaClientTrait: a new RequestKey::BrokerWorkload variant carries the pod uid and its WorkloadInfo, and BrokerWorkloadKey extracts them for SpiffeBrokerClient. CertRequest survives only as the attestor's input, built from the cache key, which leaves attestor/channel/bundles/ svid_source untouched from upstream. Consequently the PR's side-channels are dropped: CertChannel no longer records a workload (the key carries it), start_fetch_with_key collapses back into start_fetch, and new_proxies_from_factory no longer threads an inpod_context, since LocalWorkloadInformation already derives the uid from the workload it holds. The SPIRE delegated-identity provider is unchanged and remains the default; the broker is selected with CA_PROVIDER=spiffe_broker. Signed-off-by: Quang Nguyen <nguyenquang@microsoft.com>
|
Can we expect some progress on this PR anytime soon? We would really like to use Istio with Spire. If you need any help, just let us know. |
|
Hello 👋, I'll be driving this effort with @MikeZappa87 and @jaellio , I've opened the first PR derived from this. |
nddq
added a commit
to nddq/ztunnel
that referenced
this pull request
Aug 25, 2026
Re-key the SecretManager cache from Identity to CacheKey. The key is either Identity or Workload. Identity keys collapse all workloads that share a SPIFFE identity into one entry, which matches per-identity issuers (Istio CA) and preserves the current behavior. Workload keys are keyed by (identity, pod UID) and carry the workload context as payload, excluded from Hash/Eq via educe. Per-workload issuers need that context to attest every fetch, including background refreshes. Keeping it on the key avoids a side table that the refresh loop would have to re-join on every fetch. CaClientTrait::fetch_certificate now takes the cache key. The Istio CA client uses only the identity part, so the CSR path is unchanged; a debug assertion documents that it must never receive workload keys. fetch_workload_certificate and forget_workload_certificate are the new per-workload entry points. Nothing calls them yet. forget_certificate removes every entry whose identity matches, and the worker drops the per-key retry backoff on forget before the liveness check, so forgotten keys neither pin their state for the worker's lifetime nor pass a stale escalated backoff to a re-added entry. collect_certs passes the full cache key to its callback. The admin certs dump gains an optional uid field, so two same-identity rows stay distinguishable, the identity field stays a parseable SPIFFE URI, and the sort is deterministic. cert_fetcher gets its own identity-based PrefetchRequest enum (fixed at warmup priority), and the manager's Request enum becomes private. Worker logs keep the id field name; workload-keyed values append the pod UID. This is groundwork for the SPIFFE Broker provider (istio#1936, istio/istio#42339), where two pods that share a ServiceAccount each get their own attested SVID. Signed-off-by: Quang Nguyen <28567936+nddq@users.noreply.github.com>
nddq
added a commit
to nddq/ztunnel
that referenced
this pull request
Aug 25, 2026
Re-key the SecretManager cache from Identity to CacheKey. The key is either Identity or Workload. Identity keys collapse all workloads that share a SPIFFE identity into one entry, which matches per-identity issuers (Istio CA) and preserves the current behavior. Workload keys are keyed by (identity, pod UID) and carry the workload context as payload, excluded from Hash/Eq via educe. Per-workload issuers need that context to attest every fetch, including background refreshes. Keeping it on the key avoids a side table that the refresh loop would have to re-join on every fetch. CaClientTrait::fetch_certificate now takes the cache key. The Istio CA client uses only the identity part, so the CSR path is unchanged; a debug assertion documents that it must never receive workload keys. fetch_workload_certificate and forget_workload_certificate are the new per-workload entry points. Nothing calls them yet. forget_certificate removes every entry whose identity matches, and the worker drops the per-key retry backoff on forget before the liveness check, so forgotten keys neither pin their state for the worker's lifetime nor pass a stale escalated backoff to a re-added entry. collect_certs passes the full cache key to its callback. The admin certs dump gains an optional uid field, so two same-identity rows stay distinguishable, the identity field stays a parseable SPIFFE URI, and the sort is deterministic. cert_fetcher gets its own identity-based PrefetchRequest enum (fixed at warmup priority), and the manager's Request enum becomes private. Worker logs keep the id field name; workload-keyed values append the pod UID. This is groundwork for the SPIFFE Broker provider (istio#1936, istio/istio#42339), where two pods that share a ServiceAccount each get their own attested SVID. Signed-off-by: Quang Nguyen <28567936+nddq@users.noreply.github.com>
nddq
added a commit
to nddq/ztunnel
that referenced
this pull request
Aug 25, 2026
Re-key the SecretManager cache from Identity to CacheKey. The key is either Identity or Workload. Identity keys collapse all workloads that share a SPIFFE identity into one entry, which matches per-identity issuers (Istio CA) and preserves the current behavior. Workload keys are keyed by (identity, pod UID) and carry the workload context as payload, excluded from Hash/Eq via educe. Per-workload issuers need that context to attest every fetch, including background refreshes. Keeping it on the key avoids a side table that the refresh loop would have to re-join on every fetch. CaClientTrait::fetch_certificate now takes the cache key. The Istio CA client uses only the identity part, so the CSR path is unchanged. It fails closed with an error when it receives a workload key. fetch_workload_certificate and forget_workload_certificate are the new per-workload entry points. Nothing calls them yet. forget_certificate removes every entry whose identity matches, and forget_workload_certificate removes one workload's entry. The worker drops the per-key retry backoff when it drains a forget. Forgotten keys do not pin their state, and a re-added entry does not inherit a stale escalated backoff. collect_certs passes the full cache key to its callback. The admin certs dump gains an optional uid field, so two same-identity rows stay distinguishable, the identity field stays a parseable SPIFFE URI, and the sort is deterministic. cert_fetcher gets its own identity-based PrefetchRequest enum (fixed at warmup priority), and the manager's Request enum becomes private. Worker logs keep the id field name; workload-keyed values append the pod UID. This is groundwork for the SPIFFE Broker provider (istio#1936, istio/istio#42339), where two pods that share a ServiceAccount each get their own attested SVID. Signed-off-by: Quang Nguyen <28567936+nddq@users.noreply.github.com>
nddq
added a commit
to nddq/ztunnel
that referenced
this pull request
Aug 25, 2026
Re-key the SecretManager cache from Identity to CacheKey. The key is either Identity or Workload. Identity keys collapse all workloads that share a SPIFFE identity into one entry, which matches per-identity issuers (Istio CA) and preserves the current behavior. Workload keys are keyed by (identity, pod UID) and carry the workload context as payload, excluded from Hash/Eq via educe. Per-workload issuers need that context to attest every fetch, including background refreshes. Keeping it on the key avoids a side table that the refresh loop would have to re-join on every fetch. CaClientTrait::fetch_certificate now takes the cache key. The Istio CA client uses only the identity part, so the CSR path is unchanged. It fails closed with an error when it receives a workload key. fetch_certificate_by_workload and forget_certificate_by_workload are the new per-workload entry points, named after the fetch_workload_by_* convention. Nothing calls them yet. forget_certificate removes every entry whose identity matches, and forget_certificate_by_workload removes one workload's entry. The worker drops the per-key retry backoff when it drains a forget. Forgotten keys do not pin their state, and a re-added entry does not inherit a stale escalated backoff. collect_certs passes the full cache key to its callback. The admin certs dump gains an optional uid field, so two same-identity rows stay distinguishable, the identity field stays a parseable SPIFFE URI, and the sort is deterministic. cert_fetcher gets its own identity-based PrefetchRequest enum (fixed at warmup priority), and the manager's Request enum becomes private. Worker logs keep the id field name; workload-keyed values append the pod UID. This is groundwork for the SPIFFE Broker provider (istio#1936, istio/istio#42339), where two pods that share a ServiceAccount each get their own attested SVID. Signed-off-by: Quang Nguyen <28567936+nddq@users.noreply.github.com>
nddq
added a commit
to nddq/ztunnel
that referenced
this pull request
Sep 3, 2026
Re-key the SecretManager cache from Identity to CacheKey. The key is either Identity or Workload. Identity keys collapse all workloads that share a SPIFFE identity into one entry, which matches per-identity issuers (Istio CA) and preserves the current behavior. Workload keys are keyed by (identity, pod UID) and carry the workload context as payload, excluded from Hash/Eq via educe. Per-workload issuers need that context to attest every fetch, including background refreshes. Keeping it on the key avoids a side table that the refresh loop would have to re-join on every fetch. CaClientTrait::fetch_certificate now takes the cache key. The Istio CA client uses only the identity part, so the CSR path is unchanged. It fails closed with an error when it receives a workload key. fetch_certificate_by_workload and forget_certificate_by_workload are the new per-workload entry points, named after the fetch_workload_by_* convention. Nothing calls them yet. forget_certificate removes every entry whose identity matches, and forget_certificate_by_workload removes one workload's entry. The worker drops the per-key retry backoff when it drains a forget. Forgotten keys do not pin their state, and a re-added entry does not inherit a stale escalated backoff. collect_certs passes the full cache key to its callback. The admin certs dump gains an optional uid field, so two same-identity rows stay distinguishable, the identity field stays a parseable SPIFFE URI, and the sort is deterministic. cert_fetcher gets its own identity-based PrefetchRequest enum (fixed at warmup priority), and the manager's Request enum becomes private. Worker logs keep the id field name; workload-keyed values append the pod UID. This is groundwork for the SPIFFE Broker provider (istio#1936, istio/istio#42339), where two pods that share a ServiceAccount each get their own attested SVID. Signed-off-by: Quang Nguyen <28567936+nddq@users.noreply.github.com>
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
8 participants
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.
Please ignore for now. The SPIFFE broker api is still not merged however the majority of the specification is ironed out, small changes still need to be made. I will rebase and update this branch. This however fully works with the k8s workload reference approach, the pid approach has not been implemented as it probably wouldn't be used per the last istio community sync (The pid code was actually removed so it would explain why some of the abstractions exist, truth to be told, they probably could be removed as well). It can be added as the design is extensible enough. Will need to move some of the code possibly out of this code base since it can be used as a larger client library in rust, everything is just in one place to make things easier. This branch includes a script to setup/teardown/verify in kind.