feat(credentials): add an explicit workload identity auth type for Azure Key Vault - #3485
Open
khrisrichardson wants to merge 1 commit into
Open
khrisrichardson wants to merge 1 commit into
khrisrichardson wants to merge 1 commit into
Conversation
Contributor
AI Session Checks —
|
| Status | Policy | Messages |
|---|---|---|
| ✅ Passed | secrets-detection |
- |
✅ sast-scan
| Status | Policy | Messages |
|---|---|---|
| ✅ Passed | owasp-top10-2025 |
- |
| ✅ Passed | sast |
- |
| ✅ Passed | cwe-top25 |
- |
| ✅ Passed | cwe-top26-40-cusp |
- |
⚠️ iac-scan — 1 failing
| Status | Policy | Messages |
|---|---|---|
iac-misconfiguration |
Base64 High Entropy String in "deployment/chainloop/values.yaml" (error) |
✅ security-context — no advisories
Nothing this change touches has a recorded security-fix history.
View security context ↗ · Security context documentation ↗
⏭️ 2 scans not applied
| Scan | Reason |
|---|---|
vulnerability-scan |
no manifest/lockfile changed |
github-actions-scan |
no workflow files changed |
PR validation — ⚠️ 1 failing
| Status | Policy | Material | Messages |
|---|---|---|---|
| ✅ Passed | pr-description-required |
pr-info |
- |
pr-min-approvals |
pr-info |
|
|
| ✅ Passed | pr-user-story-linked |
pr-info |
- |
Powered by Chainloop and Chainloop Trace
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
All reported issues were addressed across 7 files
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
khrisrichardson
force-pushed
the
feat/azure-key-vault-workload-identity
branch
from
September 29, 2026 00:00
1c0f566 to
aad673c
Compare
Member
|
Thank you for this contribution. Before we can merge it, please fix these items:
|
…ure Key Vault AzureKeyVault gains an auth_type enum. AUTH_TYPE_WORKLOAD_IDENTITY authenticates as client_id through AKS Workload Identity, using the federated token the workload identity webhook projects into the pod, so no client secret is stored. AUTH_TYPE_CREDENTIALS keeps the service principal client secret, and AUTH_TYPE_UNSPECIFIED is treated as AUTH_TYPE_CREDENTIALS, so existing configurations do not change. The operator must select workload identity explicitly. The manager rejects AUTH_TYPE_CREDENTIALS without a client secret, so a forgotten secret fails at startup instead of silently switching the authentication method, and rejects AUTH_TYPE_WORKLOAD_IDENTITY with a client secret. The chart exposes secretsBackend.azureKeyVault.authType and renders client_secret only for AUTH_TYPE_CREDENTIALS. The README documents the pod label and service account annotation that workload identity needs. Assisted-by: Claude Code Signed-off-by: Khris Richardson <khris.richardson@gmail.com>
khrisrichardson
force-pushed
the
feat/azure-key-vault-workload-identity
branch
from
October 1, 2026 17:59
9dc57b0 to
b25743f
Compare
khrisrichardson
changed the title
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
2 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.
Part of #3488.
The Azure Key Vault backend authenticated only with a service principal client secret: a long-lived credential that has
to be stored and rotated. AKS Workload Identity issues the pod a federated token for the same app registration instead.
Following the review of #3486, the operator now selects the mode explicitly.
AzureKeyVaultgains anauth_typeenum:AUTH_TYPE_CREDENTIALS(andAUTH_TYPE_UNSPECIFIED, so existing configurations do not change): the client secretis used, as before. A missing secret is still an error.
AUTH_TYPE_WORKLOAD_IDENTITY: the tenant and client ID are used with azidentity'sWorkloadIdentityCredential,which reads the token that the workload identity webhook projects (
AZURE_FEDERATED_TOKEN_FILE). Setting a clientsecret is an error, and so is a missing token file.
defined_only), and by the manager.Chart:
secretsBackend.azureKeyVault.authType(defaultAUTH_TYPE_CREDENTIALS).client_secretrenders only forAUTH_TYPE_CREDENTIALS. A secret set with workload identity, or an unknownauthType, fails at template time. Chartversion bumped to 1.451.1.
To use workload identity, the pods need the
azure.workload.identity/use: "true"label and the controlplane and casservice accounts need the
azure.workload.identity/client-id: <clientID>annotation. The README shows both. The labelgoes through
commonLabels, becausecontrolplane.podLabelsandcas.podLabelscurrently feed only the affinityrules and never reach the pod template.
AI assistance: this PR was written with the help of Claude Code. Each commit carries an
Assisted-by: Claude Codetrailer.