- \n
- Project context<\/a><\/li>\n
- Pre-requisites<\/a><\/li>\n
- Running the bot locally<\/a><\/li>\n
- Lets create the AKS and deploy the platform<\/a><\/li>\n
- Create the AKS and configure it<\/a><\/li>\n
- Deploy the service into AKS<\/a><\/li>\n
- Access it<\/a><\/li>\n
- So how is it getting the token?<\/a><\/li>\n
- 1. The Two-Fold Path to Authentication<\/a><\/li>\n
- 2. Setting Up Your Local Development<\/a><\/li>\n
- 3. Integrating AAD with Python via LangChain<\/a><\/li>\n
- In Conclusion<\/a><\/li>\n
- AKS deployment. Microsoft Entra Workload ID with AKS<\/a><\/li>\n
- How it works<\/a><\/li>\n
- Service Account Annotations<\/a><\/li>\n
- Pod Labels<\/a><\/li>\n
- Lets see the components in Azure<\/a><\/li>\n
- Useful docs<\/a><\/li>\n
- Summary<\/a><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
Project context<\/h2>\n
Our project was to address a customer challenge that appears to be quite common in large companies: while a wealth of information was available to the Team Members, it was often hard to find and there were occasional concerns regarding its relevance and currency. This led to Team Members either reaching out to Support Teams for help or going directly to subject matter experts, creating inefficiencies in their operations. Collaborating closely, we developed a chatbot system, powered by Azure OpenAI and LangChain, designed to give quick answers to queries in a Q&A format. The deployment had to follow the customer\u2019s production requirements, which included the use of AKS and avoiding the use of secrets. If credentials were used, there had to be a plan to rotate them frequently. The platform was required to integrate with Azure OpenAI, meaning that the chatbot needed credentials to consume the resources. The use of Azure Workload Identities in AKS allowed us to run the platform, consume Azure OpenAI resources and comply with the customer’s requirements in a secure way.<\/p>\n
Pre-requisites<\/h2>\n
- \n
- An Azure subscription. Create one for free<\/a><\/li>\n
- Access granted to Azure OpenAI in the desired Azure subscription. (Currently, you must submit an application to access Azure OpenAI Service. To apply for access, complete this form<\/a>. If you need assistance, open an issue on this repository to contact Microsoft.)<\/li>\n
- VScode<\/a> with Devcontainer extension<\/a><\/li>\n
- Clone repository https:\/\/github.com\/jsburckhardt\/gradio-aks<\/a><\/li>\n
- An Azure OpenAI instance with gpt-35 or gpt4 deployments. You can follow the instructions here<\/a> to create the resources. As an alternative, a script to deploy resources can be found in the source code.
pre-requisites.sh<\/code><\/a><\/li>\n- Docker<\/a> (if running locally in Devcontainer)<\/li>\n<\/ul>\n
Running the bot locally<\/h2>\n
- \n
- \n
Open in devcontainer<\/a> or GitHub Codespaces<\/a><\/p>\n<\/li>\n
- \n
Create your
.env<\/code> file. For my example it looks like this:<\/p>\nOPENAI_API_TYPE=azure_ad\r\nOPENAI_API_BASE=<openai url>\r\nOPENAI_API_VERSION=2023-08-01-preview\r\nTEMPERATURE=0.9\r\nDEPLOYMENT_NAME=gpt-35-turbo<\/code><\/pre>\n<\/li>\n- \n
Instead of using the OpenAI token, we will be using the user’s roles. Run
az login<\/code><\/p>\n<\/li>\n- \n
Now, by default users don’t have the
Cognitive Services User<\/code> role. Here we will be adding the user role to the resource group hosting the Azure OpenAI<\/p>\nexport RG=<rg with ai resource>\r\nexport user=$(az ad signed-in-user show --query \"userPrincipalName\" -o tsv)\r\nexport resourceId=$(az group show -g $RG --query \"id\" -o tsv)\r\naz role assignment create --role \"Cognitive Services User\" --assignee $user --scope $resourceId<\/code><\/pre>\nWait couple of minutes for the role to be propagated<\/p>\n<\/li>\n
- \n
Time to run the application. Run
make gradio<\/code>, visit http:\/\/localhost:8087<\/a> and ask a question – it has memory.\n![\"make-command\"](\"https:\/\/devblogs.microsoft.com\/ise\/wp-content\/uploads\/sites\/55\/2024\/02\/aks-workload-identity-and-azure-openai-make-gradio.png\")
\n![\"bootstrap\"](\"https:\/\/devblogs.microsoft.com\/ise\/wp-content\/uploads\/sites\/55\/2024\/02\/aks-workload-identity-and-azure-openai-bootstrap.png\")
\n![\"Chat\"](\"https:\/\/devblogs.microsoft.com\/ise\/wp-content\/uploads\/sites\/55\/2024\/02\/aks-workload-identity-and-azure-openai-chat.png\")
<\/p>\n<\/li>\n<\/ol>\nIn summary, you can see the application is running without requiring to pull the OpenAI keys.<\/p>\n
Lets create the AKS and deploy the platform<\/h2>\n
Create the AKS and configure it<\/h3>\n
- \n
- \n
Create the AKS with
oidc-issuer<\/code>,enable workload-identity<\/code> andenable managed-identity<\/code>. More details about the requirements and limitations can be found here<\/a>. For the example we will be usingdefault<\/code> namespace.<\/p>\n# Create AKS cluster\r\naz aks create -g \"${RESOURCE_GROUP}\" -n \"${CLUSTER_NAME}\" --node-count 1 --enable-oidc-issuer --enable-workload-identity --enable-managed-identity<\/code><\/pre>\n<\/li>\n- \n
Now lets configure the identity. Get OIDC URL, create the identity and assign the
Cognitive Services User<\/code> role.<\/p>\n# Get OIDC issuer URL\r\nAKS_OIDC_ISSUER=\"$(az aks show -n \"${CLUSTER_NAME}\" -g \"${RESOURCE_GROUP}\" --query \"oidcIssuerProfile.issuerUrl\" -otsv)\"\r\n\r\n# Create user-assigned identity\r\nUSER_ASSIGNED_IDENTITY_NAME=<user name>\r\naz identity create --name \"${USER_ASSIGNED_IDENTITY_NAME}\" --resource-group \"${RESOURCE_GROUP}\" --location \"${LOCATION}\"\r\n\r\n# Assign role to user-assigned identity\r\nRESOURCE_ID=\"$(az group show -g \"${RESOURCE_GROUP}\" --query \"id\" -o tsv)\"\r\naz role assignment create --role \"Cognitive Services User\" --assignee \"$(az identity show --resource-group \"${RESOURCE_GROUP}\" --name \"${USER_ASSIGNED_IDENTITY_NAME}\" --query 'clientId' -otsv)\" --scope \"${RESOURCE_ID}\"<\/code><\/pre>\n<\/li>\n- \n
Connect to the cluster since we require to deploy the service account that is required for the federation<\/p>\n
az aks get-credentials -g \"${RESOURCE_GROUP}\" -n \"${CLUSTER_NAME}\" -a<\/code><\/pre>\n<\/li>\n- \n
Create the service account in AKS in
default<\/code> namespace e.g.SERVICE_ACCOUNT_NAMESPACE=default<\/code><\/p>\n# Create Kubernetes service account\r\ncat <<EOF | kubectl apply -f -\r\napiVersion: v1\r\nkind: ServiceAccount\r\nmetadata:\r\n annotations:\r\n azure.workload.identity\/client-id: $(az identity show --resource-group \"${RESOURCE_GROUP}\" --name \"${USER_ASSIGNED_IDENTITY_NAME}\" --query 'clientId' -otsv)\r\n name: \"${SERVICE_ACCOUNT_NAME}\"\r\n namespace: \"${SERVICE_ACCOUNT_NAMESPACE}\"\r\nEOF<\/code><\/pre>\n<\/li>\n- \n
Federate the account and the managed identity.<\/p>\n
FEDERATED_IDENTITY_CREDENTIAL_NAME=\"gradio-app-federated-credential\"\r\n\r\naz identity federated-credential create --name \"${FEDERATED_IDENTITY_CREDENTIAL_NAME}\" --identity-name \"${USER_ASSIGNED_IDENTITY_NAME}\" --resource-group \"${RESOURCE_GROUP}\" --issuer \"${AKS_OIDC_ISSUER}\" --subject \"system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME}\"<\/code><\/pre>\n<\/li>\n<\/ol>\nDeploy the service into AKS<\/h3>\n
Now we have everything we need to deploy the application. It is required for the pod to use the service account and have the label
azure.workload.identity\/use: \"true\"<\/code>. For deploying into the cluster, we will be using the container created in the source code repository. In other wordsghcr.io\/jsburckhardt\/gradio-aks\/chatbot:latest<\/code>. So, lets get into the deployment:<\/p>\n- \n
- \n
Update the values under the
release<\/code> folder. There are two manifests that were used to deploy in parallel two chats with different engines.<\/p>\n<\/li>\n- \n
If you use the code in the repository, all you have to update is the environment section with your resources. Update both files if you want to deploy two resources in parallel:
release\/manifest-gpt4.yaml<\/code> andrelease\/manifest.yaml<\/code><\/p>\n![\"Manifest\"](\"https:\/\/devblogs.microsoft.com\/ise\/wp-content\/uploads\/sites\/55\/2024\/02\/aks-workload-identity-and-azure-openai-manifest.png\")
<\/p>\n<\/li>\n- \n
Apply the manifest<\/p>\n
kubectl apply -f release<\/code><\/pre>\n<\/li>\n<\/ol>\nAccess it<\/h3>\n
Once the resources are deployed, you can use
k9s<\/code> inside the devcontainer to check the pods running. You should see something similar to this:<\/p>\n![\"Pods_running\"](\"https:\/\/devblogs.microsoft.com\/ise\/wp-content\/uploads\/sites\/55\/2024\/02\/aks-workload-identity-and-azure-openai-pods.png\")
<\/p>\nTo get the endpoint, inside
k9s<\/code> list theservices<\/code>:<\/p>\n![\"SVCs_runnings\"](\"https:\/\/devblogs.microsoft.com\/ise\/wp-content\/uploads\/sites\/55\/2024\/02\/aks-workload-identity-and-azure-openai-svcs.png\")
<\/p>\nNow you can use the external IP to access the resource.<\/p>\n
![\"Running](\"https:\/\/devblogs.microsoft.com\/ise\/wp-content\/uploads\/sites\/55\/2024\/02\/aks-workload-identity-and-azure-openai-running.png\")
<\/p>\nSo how is it getting the token?<\/h2>\n
To fully harness the capabilities of Azure OpenAI, authentication is the key. Understanding your options and choosing the right method can be the difference between a seamless experience and a tangled web of complexities. So, let’s break down the process.<\/p>\n
1. The Two-Fold Path to Authentication<\/h3>\n
- \n
- \n
API Key<\/strong>: This is the quickest and easiest option. If you’re looking to dive into Azure OpenAI without much ado, your API key is readily available in the Azure portal, specifically within your Azure OpenAI resource section.<\/p>\n<\/li>\n
- \n
Azure Active Directory (AAD)<\/strong>: For those with intricate security protocols, the AAD offers a more robust solution. Detailed guidelines on integrating AAD with Azure OpenAI are available here<\/a>.<\/p>\n<\/li>\n<\/ul>\n
2. Setting Up Your Local Development<\/h3>\n
If you’re developing on your local machine, ensure:<\/p>\n
- \n
- \n
Azure CLI is Installed<\/strong>: If not, download and install the Azure CLI<\/a>. Once done, initiate it with the
az login<\/code> command.<\/p>\n<\/li>\n- \n
Azure Role Assignment<\/strong>: Grant the “Cognitive Services OpenAI User” role specific to your Azure OpenAI resource. This pivotal step allows you to procure a token from AAD for Azure OpenAI usage. This role can be assigned to a diverse range of entities \u2013 from a user or group to a service principal or even a managed identity. Delve deeper into Azure OpenAI RBAC roles here<\/a>.<\/p>\n<\/li>\n<\/ul>\n
3. Integrating AAD with Python via LangChain<\/h2>\n
- \n
- \n
Install Required Package<\/strong>: Kick off by installing the
azure-identity<\/code> package. In our case we are using python package<\/a><\/p>\n<\/li>\n- \n
Set Up the Environment<\/strong>: Update the
OPENAI_API_TYPE<\/code> environment variable toazure_ad<\/code>. We set up the variables in.env<\/code> for local development. In the AKS we are using the manifestenv<\/code> property to set the values.<\/p>\n<\/li>\n- \n
Fetch the Token<\/strong>: Utilize the
DefaultAzureCredential<\/code> class to obtain your token from AAD. The simple method is invoking theget_token<\/code> function. Here’s a snippet:<\/p>\n<\/li>\n<\/ul>\ntoken = DefaultAzureCredential().get_token()<\/code><\/pre>\nIf you want to get more control over the options to generate the token, you can use the class
ChainedTokenCredential<\/code> and provide the list and order of credentials you want to use in your flow. For example, if you want to use ManagedIdentity and fallback to AzureCLI credentials. We could create our credentials instance as:<\/p>\nfrom azure.identity import ChainedTokenCredential, ManagedIdentityCredential, AzureCliCredential\r\n\r\ncredential = ChainedTokenCredential(\r\n ManagedIdentityCredential(),\r\n AzureCliCredential()\r\n)<\/code><\/pre>\nDefaultAzureCredential<\/strong> stands as a versatile credential, tailored to handle a myriad of Azure SDK authentication scenarios. The essence of its flexibility stems from its adaptability; the identity it employs is contingent upon the environment. In a bid to fetch an access token, it sequentially requests these identities, halting once a token is obtained:<\/p>\n
- \n
- Environment-based service principal (EnvironmentCredential details<\/a>).<\/li>\n
- Azure workload identity (through the WorkloadIdentityCredential<\/strong> when set by its webhook).<\/li>\n
- Azure managed identity (ManagedIdentityCredential details<\/a>).<\/li>\n
- For Windows users: A Microsoft application sign-in. SharedTokenCacheCredential<\/strong> dives deeper<\/a>.<\/li>\n
- The Azure CLI logged-in identity.<\/li>\n
- Azure PowerShell logged-in identity.<\/li>\n
- Azure Developer CLI logged-in identity.<\/li>\n<\/ul>\n
While this default procedure serves most, it’s malleable, courtesy of configurable keyword arguments.<\/p>\n
Instantiating the DefaultAzureCredential<\/strong> involves several keyword parameters, granting developers fine-grain control. These parameters range from defining the Azure AD endpoint authority to toggling specific credentials on or off.<\/p>\n
For instance, if you wish to exclude Azure PowerShell or the Azure Developer CLI, just set
exclude_powershell_credential<\/code> orexclude_developer_cli_credential<\/code> to True respectively. Each exclusion parameter bears a clear name, making configurations intuitive.<\/p>\nTwo primary methods encapsulate the essence of this class:<\/p>\n
- \n
- close()<\/strong>: To terminate the transport session of each chained credential.<\/li>\n
- get_token(scopes, claims, tenant_id)<\/strong>: Integral to access token acquisition, this method is invoked automatically by Azure SDK clients. It requisitions an access token for the defined scopes, and can incorporate additional claims or specify a tenant.<\/li>\n<\/ol>\n
To fetch an access token in Python:<\/p>\n
token = credential.get_token('desired-scope')<\/code><\/pre>\nIn case of authentication failures, an exception (ClientAuthenticationError) is raised, outlining each authentication attempt and the corresponding error.<\/p>\n
In Conclusion<\/h3>\n
The DefaultAzureCredential class embodies the marriage of simplicity with flexibility, rendering Azure SDK authentication a breeze for developers. By offering a range of identities and configurable behaviors, it ensures that diverse scenarios and specific needs are catered to effortlessly.<\/p>\n
AKS deployment. Microsoft Entra Workload ID with AKS<\/h2>\n
When working with Azure Kubernetes Services (AKS), you might need to access resources like Azure Key Vault or Microsoft Graph. That’s where Microsoft Entra Workload ID<\/strong> comes in. It taps into Kubernetes’ built-in features to work with external identity providers.<\/p>\n
It uses something called the Service Account Token Volume Projection<\/strong>. This means pods can take on a Kubernetes identity through service accounts. This setup, combined with OIDC federation, lets Kubernetes apps securely tap into Azure resources using the Microsoft Entra ID.<\/p>\n
For developers, the good news is that this all plays nice with Azure Identity client libraries and the MSAL suite, especially if you’re into application registration.<\/p>\n
How it works<\/h3>\n
A workload identity flow, is a sequence of steps for authenticating a workload (such as an application or service) running on Azure Kubernetes Service (AKS) and authorizing it to access Azure resources. Here’s a step-by-step summary of the flow:<\/p>\n
- \n
- \n
Kubelet<\/strong>: Starts the flow by projecting a service account token to the workload. This token is available at a configurable file path.<\/p>\n<\/li>\n
- \n
AKS Workload<\/strong>: The workload retrieves the projected service account token and sends it along with a request for an Azure Active Directory (AD) access token.<\/p>\n<\/li>\n
- \n
Azure Active Directory<\/strong>: Receives the service account token, checks the trust on the application (i.e., verifies that the token is from a trusted source), and validates the token.<\/p>\n<\/li>\n
- \n
Azure AD<\/strong>: Once validation is successful, Azure AD issues an access token back to the AKS workload.<\/p>\n<\/li>\n
- \n
AKS Workload<\/strong>: Uses the received Azure AD access token to access Azure resources.<\/p>\n<\/li>\n<\/ol>\n
This flow ensures that only authenticated and authorized workloads can interact with Azure resources, enhancing security by using Azure Active Directory as the central authority for trust and token issuance.<\/p>\n
Additional details can be found in the following MS documentation Use Microsoft Entra Workload ID with Azure Kubernetes Service (AKS)<\/a><\/p>\n
In kubernetes world. For those familiar with Microsoft Entra pod-managed identity<\/a>, consider a service account as its Kubernetes counterpart – the Azure Identity. But, unlike the Azure Identity, a service account is baked right into the core Kubernetes API, not added as a Custom Resource Definition (CRD). Below, we’ll delve into the various labels and annotations available, guiding you on how to swap the service account token for a Microsoft Entra access token.<\/p>\n
Service Account Annotations<\/h3>\n
There are 3 main annotations to consider
azure.workload.identity\/client-id<\/code>,azure.workload.identity\/tenant-id<\/code> andazure.workload.identity\/service-account-token-expiration<\/code>. Have a look in this section for more details Service Account Annotations<\/a><\/p>\nPod Labels<\/h3>\n
Regarding the pod labels, there are 4 we should consider
azure.workload.identity\/service-account-token-expiration<\/code>,azure.workload.identity\/skip-containers<\/code>,azure.workload.identity\/inject-proxy-sidecar<\/code> andazure.workload.identity\/proxy-sidecar-port<\/code>. For specifics, have a look into this section Pod Labels<\/a>.<\/p>\nLets see the components in Azure<\/h3>\n
- \n
- \n
Managed identity<\/p>\n
![\"managed_identity\"](\"https:\/\/devblogs.microsoft.com\/ise\/wp-content\/uploads\/sites\/55\/2024\/02\/aks-workdload-identity-and-azure-openai-managed_identity.png\")
<\/p>\n<\/li>\n - \n
Role assigned to the managed identity<\/p>\n
![\"role_assigned\"](\"https:\/\/devblogs.microsoft.com\/ise\/wp-content\/uploads\/sites\/55\/2024\/02\/aks-workdload-identity-and-azure-openai-role_assigned.png\")
<\/p>\n<\/li>\n - \n
Service account with the managed identity client-id<\/p>\n
![\"service_account\"](\"https:\/\/devblogs.microsoft.com\/ise\/wp-content\/uploads\/sites\/55\/2024\/02\/aks-workdload-identity-and-azure-openai-service_account.png\")
<\/p>\n<\/li>\n - \n
Federation<\/p>\n
![\"federation_details\"](\"https:\/\/devblogs.microsoft.com\/ise\/wp-content\/uploads\/sites\/55\/2024\/02\/aks-workdload-identity-and-azure-openai-federation_details.png\")
<\/p>\n<\/li>\n - \n
Apply<\/p>\n
kubectl apply -f release<\/code><\/pre>\n![\"apply_manifest\"](\"https:\/\/devblogs.microsoft.com\/ise\/wp-content\/uploads\/sites\/55\/2024\/02\/aks-workdload-identity-and-azure-openai-apply_manifest.png\")
<\/p>\n![\"pods_running\"](\"https:\/\/devblogs.microsoft.com\/ise\/wp-content\/uploads\/sites\/55\/2024\/02\/aks-workdload-identity-and-azure-openai-pods_running.png\")
<\/p>\n![\"pod_description\"](\"https:\/\/devblogs.microsoft.com\/ise\/wp-content\/uploads\/sites\/55\/2024\/02\/aks-workdload-identity-and-azure-openai-pod_description.png\")
<\/p>\n<\/li>\n<\/ol>\nUseful docs<\/h2>\n
- \n
- Azure Managed Identities with Workload Identity Federation | Identity in the cloud (identitydigest.com)<\/a><\/li>\n
- Tutorial – Use a workload identity with an application on Azure Kubernetes Service (AKS) – Azure Kubernetes Service | Microsoft Learn<\/a><\/li>\n
- How to configure Azure OpenAI Service with managed identities – Azure OpenAI | Microsoft Learn<\/a><\/li>\n
- Comparing Azure pod vs workload identity<\/a><\/li>\n
- Azure AD workload identity federation with Kubernetes<\/a><\/li>\n
- Azure Managed Identities with Workload Identity Federation<\/a><\/li>\n<\/ul>\n
Summary<\/h2>\n
This blog post examines the integration of Azure OpenAI with Azure Kubernetes Services (AKS) through Workload Identities. It outlines the security and efficiency benefits of using Workload Identities for application authentication, eliminating the need for secret management. The adaptability of Workload Identities across different hosting environments is also highlighted.<\/p>\n
The post details the setup process for Azure AD authentication and the utilization of Microsoft Entra Workload ID for Azure resource access within AKS. It provides a practical guide on running applications locally, creating an AKS, deploying services to AKS, and accessing these services.<\/p>\n
Furthermore, the blog discusses key Azure components such as Managed Identity and Federation, essential in this integration process. This guide is designed to assist developers in effectively using Azure OpenAI resources in AKS, leveraging the capabilities of Workload Identities.<\/p>\n","protected":false},"excerpt":{"rendered":"
This post will showcase the use of Azure OpenAI from AKS without the need for sharing secrets.<\/p>\n","protected":false},"author":114974,"featured_media":15288,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1,3451],"tags":[3447,3495,3496,3497],"class_list":["post-15283","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cse","category-ise","tag-azcli","tag-azure-openai","tag-openai","tag-workload-identities"],"acf":[],"blog_post_summary":"
This post will showcase the use of Azure OpenAI from AKS without the need for sharing secrets.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/ise\/wp-json\/wp\/v2\/posts\/15283","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/ise\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/ise\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/ise\/wp-json\/wp\/v2\/users\/114974"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/ise\/wp-json\/wp\/v2\/comments?post=15283"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/ise\/wp-json\/wp\/v2\/posts\/15283\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/ise\/wp-json\/wp\/v2\/media\/15288"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/ise\/wp-json\/wp\/v2\/media?parent=15283"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/ise\/wp-json\/wp\/v2\/categories?post=15283"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/ise\/wp-json\/wp\/v2\/tags?post=15283"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Tutorial – Use a workload identity with an application on Azure Kubernetes Service (AKS) – Azure Kubernetes Service | Microsoft Learn<\/a><\/li>\n
- Azure Managed Identities with Workload Identity Federation | Identity in the cloud (identitydigest.com)<\/a><\/li>\n
- \n
- get_token(scopes, claims, tenant_id)<\/strong>: Integral to access token acquisition, this method is invoked automatically by Azure SDK clients. It requisitions an access token for the defined scopes, and can incorporate additional claims or specify a tenant.<\/li>\n<\/ol>\n
- Azure workload identity (through the WorkloadIdentityCredential<\/strong> when set by its webhook).<\/li>\n
- \n
- \n
- \n
- \n
- \n
- \n
- Access granted to Azure OpenAI in the desired Azure subscription. (Currently, you must submit an application to access Azure OpenAI Service. To apply for access, complete this form<\/a>. If you need assistance, open an issue on this repository to contact Microsoft.)<\/li>\n
- Pre-requisites<\/a><\/li>\n