Skip to content

Move the CSR controller's variant knowledge behind an extension - #5195

Merged
caseydavenport merged 5 commits into
tigera:masterfrom
caseydavenport:casey-csr-extension
Aug 20, 2026
Merged

Move the CSR controller's variant knowledge behind an extension#5195
caseydavenport merged 5 commits into
tigera:masterfrom
caseydavenport:casey-csr-extension

Conversation

@caseydavenport

@caseydavenport caseydavenport commented Aug 14, 2026

Copy link
Copy Markdown
Member

Description

Split out of #5170 to keep that review smaller, and the first of the per-controller ones. The CSR controller had a hardcoded table of Enterprise certificates plus variant checks scattered through the reconcile, so it only signed the right things because it knew what product it was running as. That knowledge moves to an extension:

  • the signable assets and whether the signing ClusterRole is needed come from the extension
  • requests that no pod issued get their subject from a resolver the extension supplies
  • assets that more than one service account may request carry their own authorizer instead of a special case in the controller
  • the extension registers its own watches, so creating a NonClusterHost triggers a reconcile rather than waiting on an unrelated event

The core controller keeps the signing, the approval, and the request validation. With no extension registered it signs the same set it always did.

Related: CORE-13395

Release Note

None

# Conflicts:
#	pkg/enterprise/register.go
#	pkg/extensions/extensions.go
@caseydavenport
caseydavenport merged commit 6b916b4 into tigera:master Aug 20, 2026
5 of 6 checks passed
@caseydavenport
caseydavenport deleted the casey-csr-extension branch August 20, 2026 20:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants