Digital transformation is resulting in the deployment of more software workloads. Businesses are building or rewriting their software workloads using cloud-native architectures. Multi-cloud is becoming the new normal, as developers cherry-pick the cloud resources that best suit their needs. When applications or services run outside Azure and need access to Azure resources, they need secrets to authenticate to Azure AD. These secrets pose a security risk. Securely storing these secrets and regularly rotating them is an unnecessary developer burden. Azure AD workload identity federation removes the need for these secrets in selected scenarios. Developers can configure Azure AD workload identities to trust tokens issued by another identity provider. This blog post explores how you can access Azure resources from software workloads running in Amazon Web Services (AWS).

Pod identity is an open-source project that enables using Azure managed identities in Kubernetes clusters. Pod-managed identity, a public preview feature in Azure Kubernetes Service (AKS), is built upon the pod identity project. Pod identity is now deprecated and not recommended for use in your Kubernetes clusters. Azure workload identity, which is simpler to use and overcomes several limitations, replaces pod identity. Azure workload identity can be used side-by-side with pod identity, making it easy to upgrade your deployments. This blog article walks you through how you can seamlessly and gradually move each of your Kubernetes deployments from pod identity to workload identity.

Managed identities in Azure allow software workloads to access Azure resources without needing secrets. However, these identities can only be used in workloads on Azure compute like VMs, App Services, and Functions. Azure AD pod-managed identity is a public preview feature in Azure Kubernetes Service (AKS) that enables workloads in Kubernetes clusters to use managed identities. This feature is now deprecated. Azure workload identity for Kubernetes replaces pod-managed identity. Azure workload identity also addresses several limitations that exist in pod-managed identity. This blog post walks through a comparison between pod identity and workload identity.

In my recent blog post we discussed the federation support on Azure managed identities. This capability allows you to use Kubernetes service accounts to access Azure resources without needing secrets. Developers can configure their managed identities with their cluster’s OIDC issuer URL, adding trust between their Kubernetes service account and their managed identity. Since managed identities are Azure resources, you can use Azure policy to enforce rules like only using issuers trusted by your organization. This blog post walks through the use of Azure policy to achieve this control.

Yes! Workload Identity Federation is now available in public preview on user-assigned Managed Identities too! This change makes it easier for developers to access Azure resources from their software services running in Kubernetes clusters or running in the Google cloud or from GitHub Actions workflows. There have been several blogs posted on this site, such as Kubernetes, GitHub and SPIFFE, which walk through using an Azure AD application registration to configure workload identity federation. This blog walks you through using managed identities instead of application registrations to enable those scenarios.

As more applications move to the cloud, many development teams consider cloud-neutral and cloud-native technologies when architecting their deployments. Decomposing monolithic applications into multiple independent microservices can provide a simple and agile model. Kubernetes is gaining popularity as a cloud-neutral platform to deploy these microservices. This blog discusses how these individual microservices authenticate and authorize each other. It is different from the earlier blog posts on this site. Rather than a deep dive into a specific scenario or solution, I am soliciting your input on your identity needs for your software services.

In my earlier blog post we discussed how to use the preview feature of Azure AD workload identity federation in Kubernetes clusters. You can use Kubernetes service accounts to access Azure resources without storing secrets for Azure AD workload identities. This capability is now available for Secrets Store CSI drivers as well! And it makes it easier to access your Azure KeyVault secrets securely from your Kubernetes deployments.

SPIFFE is a set of open-source standards for providing identities to your software workloads. Since it is platform agnostic with possibilities such as mTLS, it is an attractive option for services deployed across platforms and cloud vendors. The Kubernetes blog post discussed how services running in a Kubernetes cluster can use Azure AD workload identity federation to access Azure resources without needing secrets. This blog post explores how services relying on SPIFFE can also use this capability to access Azure resources. No secrets are necessary.

Enterprises are increasingly using cloud-native technologies to build software workloads. Modern development practices are embracing concepts such as microservices and containers. Kubernetes is emerging as a popular platform for deploying software workloads. An earlier blog post discussed how Azure AD workload identity federation avoids the need for secrets when accessing Azure resources from Google cloud. This blog post explores how services running in a Kubernetes cluster can also use this capability to access Azure resources. No secrets are necessary.

When applications or services run in environments outside Azure, they need Azure AD application secrets to authenticate to Azure AD and access resources such as Azure and Microsoft Graph. These secrets pose a security risk if they are not stored securely and rotated regularly. Azure AD workload identity federation removes the need for these secrets in selected scenarios. Developers can configure their Azure AD applications to trust tokens issued by another identity provider. This blog post explores how you can access Azure resources without needing secrets when your services are running in the Google Cloud Platform.

GitHub announced support for federating with identity providers to get rid of secrets in the Actions workflows. Developers can now deploy from their GitHub repositories to their Azure resources using the identity of their GitHub repo and their workflow job! This avoids the need to create and store secrets from Azure AD into their GitHub repo. To support this model, Azure AD has a new capability, currently in public preview, called Workload Identity Federation. This capability allows you to configure Azure AD applications to trust the GitHub token (JWT) that represent your GitHub repo and workflow. This blog post looks under the covers on how this works end to end.

When developers build services that need to access other resources, they have to figure out how to manage the credentials for this access. When these services are running in Azure, developers can use managed identities in Azure to avoid dealing with credentials on their own. This “secret-less” model can be used even when these services need to access Amazon Web Services (AWS) resources. This lets you avoid having to store and manage AWS credentials in Azure. This blog post provides a walkthrough of how you can achieve this.

This page has moved to a new location

A single-tenant daemon service (which accesses resources within the tenant) is commonly showcased using the Azure AD Application model. However, since the daemon scenario uses a confidential client flow, you now need to deal with the application secrets. Where do you store it securely (eg: Azure KeyVault) and how do you rotate it regularly? This blog shows how you can use Managed Identities for your daemon service and get away from having to deal with credentials.

The Azure AD application model provides a great way for someone to build an app running in their developer tenant while allowing their customers to use that app in the customer’s tenant. Most examples of this pattern showcase how an admin can consent the app in their tenant and get access to Microsoft Graph data in that tenant. This also happens to be a great pattern to also access Azure resources in the other tenant. For example, your customer may ask you to encrypt their content using a key in their keyvault. This blog post gives a walkthrough on accessing Azure resources across tenant boundaries.

The continued shift to cloud computing is causing more software workloads to move to the cloud. Most new enterprise software developed these days are built natively to the cloud. These software workloads, made up of applications, scripts, services and daemons, typically need an identity to authenticate and access resources or communicate with other services. This has resulted in a dramatic increase in “workload identities” in cloud identity systems.