Use Workload Identity Federation for Windows Trusted Signing #14604
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.
This PR replaces the former client-id / client-secret authentication flow with Azure AD Workload Identity Federation in the
release.ymlworkflow.Why
AZURE_CLIENT_SECRETentirely.What changed
id-token: writepermission to thebuildjob so GitHub can issue an OIDC token.environment: release-scoped sign job. Secrets and variables live in that environment.azure-client-secretwith WIF parameters in both theazure/loginandazure/trusted-signing-actionsteps.Setup instructions
Create the environment
Settings › Environments › New environmentName it
releaseAdd protection rules for:
mainv*Add environment secrets (values will be shared privately)
AZURE_CLIENT_IDAZURE_SUBSCRIPTION_IDAZURE_TENANT_IDAdd environment variables
AZURE_CERTIFICATE_PROFILE_NAME→ElixirAZURE_TRUSTED_SIGNING_ACCOUNT_NAME→trusted-signing-elixirAfter those steps, the workflow will authenticate to Azure through Workload Identity Federation with no further secret management required.
References