Currently, the FluxInstance OIDC configuration for the Web UI requires a static clientSecret. In modern cloud environments like Azure (AKS), AWS (EKS), and GCP (GKE), managing static secrets is discouraged in favor of Workload Identity.
I would like to propose adding support for RFC 7523 (JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication). This would allow the Flux Web UI to authenticate against an OIDC provider (like Microsoft Entra ID) using a signed JWT (Client Assertion) instead of a static password.
Proposed Change
Modify the OIDC client implementation to allow for "secret-less" flows where the client proves its identity using a token projected into the Pod by the cloud provider (e.g., Azure Workload Identity).
Suggested YAML Configuration:
spec:
web:
enabled: true
authentication:
type: OAuth2
oauth2:
provider: OIDC
clientID: "00000000-0000-0000-0000-000000000000"
issuerURL: "https://microsoftonline.com"
# Enable secret-less authentication via Client Assertions
clientAssertion:
enabled: true
# For AKS/Workload Identity, the token is typically found here:
tokenPath: "/var/run/secrets/azure/tokens/azure-identity-token"Reasoning
Security: Aligns with the "Zero Trust" and "Secret-less" philosophy by removing static, long-lived credentials from the cluster.
Standardization: By implementing RFC 7523, the operator gains a standardized way to support identity-based authentication across all major cloud providers and modern IDPs (Keycloak, Okta, etc.).
Integration: This complements the work already done in RFC-0007 (Passwordless authentication for source-controller) by extending the same level of security to the management interface.
Implementation Details
Since the operator is written in Go, this can be achieved using the https://github.com/golang/oauth2 library by implementing a custom oauth2.TokenSource that generates a signed JWT as the client_assertion during the token exchange. golang/oauth2#744 might be a blocker, but it will benefit the greater community if this issue was resolved. I am also following dexidp/dex#4521, where we could get some inspiration.
Context
I am currently running Flux on AKS and would like to use Azure Workload Identity to secure the Web UI without managing Kubernetes secrets.
Disclaimer: I used AI to assist me in writing up this issue. 😅
Currently, the FluxInstance OIDC configuration for the Web UI requires a static clientSecret. In modern cloud environments like Azure (AKS), AWS (EKS), and GCP (GKE), managing static secrets is discouraged in favor of Workload Identity.
I would like to propose adding support for RFC 7523 (JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication). This would allow the Flux Web UI to authenticate against an OIDC provider (like Microsoft Entra ID) using a signed JWT (Client Assertion) instead of a static password.
Proposed Change
Modify the OIDC client implementation to allow for "secret-less" flows where the client proves its identity using a token projected into the Pod by the cloud provider (e.g., Azure Workload Identity).
Suggested YAML Configuration:
Reasoning
Security: Aligns with the "Zero Trust" and "Secret-less" philosophy by removing static, long-lived credentials from the cluster.
Standardization: By implementing RFC 7523, the operator gains a standardized way to support identity-based authentication across all major cloud providers and modern IDPs (Keycloak, Okta, etc.).
Integration: This complements the work already done in RFC-0007 (Passwordless authentication for source-controller) by extending the same level of security to the management interface.
Implementation Details
Since the operator is written in Go, this can be achieved using the https://github.com/golang/oauth2 library by implementing a custom oauth2.TokenSource that generates a signed JWT as the client_assertion during the token exchange. golang/oauth2#744 might be a blocker, but it will benefit the greater community if this issue was resolved. I am also following dexidp/dex#4521, where we could get some inspiration.
Context
I am currently running Flux on AKS and would like to use Azure Workload Identity to secure the Web UI without managing Kubernetes secrets.
Disclaimer: I used AI to assist me in writing up this issue. 😅