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.
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.