Workload Identity (OIDC) for AKS

Summary

This video explains how to use Workload Identity with OpenID Connect (OIDC) in Azure Kubernetes Service (AKS) to securely access Azure resources without managing passwords. It addresses the risks of storing sensitive data in Kubernetes secrets and introduces passwordless authentication via OIDC. The video walks through the steps to enable Workload Identity in AKS, link Kubernetes service accounts to Azure Managed Identities, and deploy applications that access Azure resources securely. It also covers advanced scenarios like one-to-one, many-to-one, and one-to-many identity mappings, providing a scalable and secure solution for accessing both Azure and external resources.

Takeaways

• 😀 Workload Identity with OpenID Connect (OIDC) in AKS enables secure, passwordless access to Azure resources from Kubernetes clusters.
• 😀 Kubernetes secrets are base64-encoded, not encrypted, and are not a secure method for storing sensitive data like passwords or tokens.
• 😀 Traditional methods like using service principals or managed identities often require managing passwords, which can lead to security risks and scalability issues.
• 😀 Workload Identity with OIDC removes the need for passwords, offering a passwordless solution that works both within and outside of Azure.
• 😀 The recommended approach for securely accessing Azure resources from Kubernetes is using workload identity with OIDC, which integrates seamlessly with Kubernetes APIs.
• 😀 The solution scales well and works with a variety of environments, including Azure, on-premise resources, and other cloud providers.
• 😀 To use workload identity, you must enable the OIDC issuer in your AKS cluster and link Kubernetes service accounts to managed identities.
• 😀 Workload Identity allows secure access to Azure resources without the need for managing service principal passwords, using federated identity credentials instead.
• 😀 The configuration steps include creating a service account, associating it with a managed identity, and enabling workload identity in AKS.
• 😀 The workload identity setup involves linking Azure resources (e.g., Azure Key Vault) to your Kubernetes workloads using managed identities and OIDC tokens.
• 😀 The demo illustrates how to set up AKS, create Azure resources, link service accounts to managed identities, and deploy workloads that securely access Azure resources.

Q & A

What is Workload Identity with OpenID Connect (OIDC) in AKS?

Workload Identity with OpenID Connect (OIDC) is a feature that enables Kubernetes workloads (such as pods) to authenticate to Azure Active Directory (Azure AD) and access Azure resources securely without requiring the use of passwords or service principal credentials.

Why is managing secrets in Kubernetes problematic?

Managing secrets in Kubernetes is problematic because Kubernetes secrets are encoded in base64 and not encrypted by default, making them vulnerable. Although they are encrypted at rest inside the etcd database, anyone with sufficient access can retrieve and decode them, posing a security risk.

What are the main options available for accessing Azure resources from Kubernetes before the introduction of Workload Identity?

Before Workload Identity, the main options included using service principals with passwords, managed identities for Azure resources, and solutions like Azure Key Vault to Kubernetes or Azure Active Directory Pod Identity. However, these solutions often required managing passwords and were limited in scalability.

What are the advantages of using Workload Identity with OIDC in AKS?

The advantages include passwordless authentication, scalability, and the ability to access both Azure and external resources securely. It also integrates natively with Kubernetes, without requiring additional Custom Resource Definitions (CRDs), and eliminates the need to manage sensitive credentials.

How does Workload Identity with OIDC work in practice within AKS?

In AKS, Workload Identity works by enabling the feature in the AKS cluster, creating a Kubernetes service account linked to an Azure Managed Identity, and using annotations to associate the service account with the Managed Identity's client ID. When a pod uses this service account, it can authenticate via OIDC to Azure AD and retrieve an access token to access Azure resources.

What is the role of Kubernetes Service Accounts in this setup?

Kubernetes Service Accounts play a key role by being linked to Azure Managed Identities. These service accounts are used by Kubernetes workloads (like pods) to authenticate to Azure AD and obtain access tokens for accessing Azure resources. Annotations are used to link the service account with the corresponding Managed Identity.

Can Workload Identity with OIDC be used to access resources outside Azure?

Yes, Workload Identity with OIDC can access both Azure resources and external resources, such as on-premise systems, other cloud providers, or other Kubernetes clusters. This is a key benefit of using OIDC for authentication.

What are the different use case scenarios for linking Kubernetes Service Accounts to Azure Managed Identities?

There are three main scenarios: 1) One-to-One: One Service Account linked to one Managed Identity. 2) Many-to-One: Multiple Service Accounts using the same Managed Identity. 3) One-to-Many: One Service Account linked to multiple Managed Identities by modifying the annotations.

What are the steps involved in setting up Workload Identity in AKS?

The setup steps include enabling the Workload Identity feature in AKS, creating a Kubernetes service account, linking it to an Azure Managed Identity using annotations, and deploying the application (pod) that uses this service account. Then, the pod can authenticate with Azure AD and access resources, such as Azure Key Vault.

How does a Kubernetes pod use a service account to access Azure resources with Workload Identity?

A Kubernetes pod uses the linked service account to authenticate with Azure AD via OIDC. It requests an access token, and Azure AD verifies the request. If valid, it returns the token, which the pod can then use to access Azure resources such as Key Vault or other services.