Sequence · 05 of 07 · Chaining

How test gets started when build finishes

Stages are separate PipelineRuns chained by events. The interesting part is identity: each hop is authenticated by Kubernetes itself, and the next stage runs as the tenant, never as the broker.

How test gets started when build finishes Sequence across six participants. The build PipelineRun's finally block posts a CDEvent with its own projected service-account token to the shared CDEvents broker. The broker's ClusterInterceptor calls the Kubernetes TokenReview API, which confirms the token and says which service account it belongs to. The broker routes the event to that tenant's own Trigger, which creates the test PipelineRun under the tenant's least-privilege service account. build PipelineRunfinally: emitCDEvents brokershared · statelessInterceptorClusterInterceptorKubernetes APITokenReviewTenant Triggertenant SA · namespacedtest PipelineRunruns as tenant SA1 · CDEVENT + OWN SA TOKEN2 · INTERCEPT3 · TOKENREVIEW4 · VALID · WHICH SA5 · ROUTE TO THIS TENANT6 · CREATESNo key material anywhere: the broker never mints or stores a credential, it only asks Kubernetes who is calling.LEGENDShared brokerPipeline runEventResponseRuns as tenant

Principle honored

Workload identity over minted secrets: the pod's own audience-bound token is the credential, verified by the API server.

What changes

  • One shared EventListener with 2 to 3 replicas, not a listener per tenant.
  • Each tenant has its own Trigger object, scoped to its own service account.
  • The same events feed DORA metrics.

Why it holds

A tenant cannot trigger another tenant's pipeline: routing follows the identity TokenReview returns, not anything in the payload.

Hangar · Glidepath