Support Azure workload identity to access Azure resources (storage blobs, etc)

[superff]

What is the underlying problem you're trying to solve?

Microsoft azure is deprecating the aad pod identity,
https://github.com/Azure/aad-pod-identity#-announcement.
AAD Pod Identity has been replaced with Azure Workload Identity

We want to use the workload identity with opa to load the policies bundles from azure storage account

Describe the ideal solution

The azure workload identity supports oauth2 authentication

but it is not the same format as the client credentials described in this
example.

https://www.openpolicyagent.org/docs/latest/configuration/#oauth2-client-credentials

https://www.openpolicyagent.org/docs/latest/configuration/#example-2

it needs a few more params

like client_assertion_type and client_assertion, but the client_assertion is a dynamic token, and it is saved under a file,

Here in this doc, it listed the environment variables output by workload identity, https://azure.github.io/azure-workload-identity/docs/quick-start.html#7-deploy-workload

I am wondering could opa load this token in this file AZURE_FEDERATED_TOKEN_FILE dynamically

      credentials:
          # https://www.openpolicyagent.org/docs/latest/configuration/#azure-managed-identities-token
          # https://arsenvlad.medium.com/azure-active-directory-workload-identity-federation-with-external-oidc-idp-4f06c9205a26
          # https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow#third-case-access-token-request-with-a-federated-credential
          # cat $AZURE_FEDERATED_TOKEN_FILE
          oauth2: 
            token_url: ${AZURE_AUTHORITY_HOST}${AZURE_TENANT_ID}/oauth2/v2.0/token
            client_id: ${AZURE_CLIENT_ID}
            client_secret: xx
            scopes: [ https://storage.azure.com/.default ] 
            additional_parameters:
              client_assertion_type: urn:ietf:params:oauth:client-assertion-type:jwt-bearer
              client_assertion:  ${AZURE_FEDERATED_TOKEN_FILE} # pass the file here to load the token dynamically, as the value is only valid for an hour or so
             additional_headers: 
              x-ms-version: 2020-04-08
              x-ms-blob-type: BlockBlob

https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow#third-case-access-token-request-with-a-federated-credential

sample token request

POST /{tenant}/oauth2/v2.0/token HTTP/1.1               // Line breaks for clarity
Host: login.microsoftonline.com:443
Content-Type: application/x-www-form-urlencoded

scope=https%3A%2F%2Fgraph.microsoft.com%2F.default
&client_id=97e0a5b7-d745-40b6-94fe-5f77d35c6e05
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6Imd4OHRHeXN5amNScUtqRlBuZDdSRnd2d1pJMCJ9.eyJ{a lot of characters here}M8U3bSUKKJDEg
&grant_type=client_credentials

Describe a "Good Enough" solution

Additional Context

[ashutosh-narkar]

I am wondering could opa load this token in this file AZURE_FEDERATED_TOKEN_FILE dynamically

OPA will simply set the key-value pairs for the additional_parameters field, it will not read that file.

We could probably make client_assertion a non-required top-level key. I don't know much about the spec but is this required for only Azure or is part of some wider spec?

[superff]

I am wondering could opa load this token in this file AZURE_FEDERATED_TOKEN_FILE dynamically

OPA will simply set the key-value pairs for the additional_parameters field, it will not read that file.

We could probably make client_assertion a non-required top-level key. I don't know much about the spec but is this required for only Azure or is part of some wider spec?

thanks @ashutosh-narkar for your quick response

this is required by Azure only, related to Azure AD, adding the keys won't help here. the azure token is a dynamic value, client_assertion( a jwt token) is saved into a file $AZURE_FEDERATED_TOKEN_FILE, and will roughly get updated every 1 hour.
opa only supports constants like client_id, client_credential in yaml template with oauth2, that is my concern

[ashutosh-narkar]

@superff if we extend the OAuth2 Client Credentials mechanism to add a new one that takes client_assertion_type and client_assertion instead of the client secret, this should be good, correct?

[superff]

@superff if we extend the OAuth2 Client Credentials mechanism to add a new one that takes client_assertion_type and client_assertion instead of the client secret, this should be good, correct?

those are not enough, the client_assertion is a token , it will expire in 1 hour or so. is it possible that opa can read this file $AZURE_FEDERATED_TOKEN_FILE and set it to the client_assertion

[ashutosh-narkar]

is it possible that opa can read this file $AZURE_FEDERATED_TOKEN_FILE and set it to the client_assertion

We could have client_assertion and client_assertion_path params where the later takes a path to a file which can be re-read on each request. Users would provide either one.

[superff]

is it possible that opa can read this file $AZURE_FEDERATED_TOKEN_FILE and set it to the client_assertion

We could have client_assertion and client_assertion_path params where the later takes a path to a file which can be re-read on each request. Users would provide either one.

that will be great, thanks

[superff]

the value will AZURE_FEDERATED_TOKEN_FILE : /var/run/secrets/azure/tokens/azure-identity-token

[ashutosh-narkar]

If you'd like to contribute this feature, feel free to do so!

[superff]

If you'd like to contribute this feature, feel free to do so!

I can contribute, need the reviewers to give some feedbacks on my draft PR.
#6014

[stale]

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days. Although currently inactive, the issue could still be considered and actively worked on in the future. More details about the use-case this issue attempts to address, the value provided by completing it or possible solutions to resolve it would help to prioritize the issue.

[podedra92]

@ashutosh-narkar with the PR closed - how did you resolve this issue?

[ashutosh-narkar]

Hey @podedra92, @superff was looking into this. The PR was closed but I don't think we merged the changes. Could be more work/investigation is still needed on it.

[stale]

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days. Although currently inactive, the issue could still be considered and actively worked on in the future. More details about the use-case this issue attempts to address, the value provided by completing it or possible solutions to resolve it would help to prioritize the issue.