PaaS

Mastering AWS EKS Deployment with Terraform: A Comprehensive Guide

October 29, 2023 Amazon, AWS, Cloud Computing, Containers, Elastic Container Registry(ECR), Elastic Kubernetes Service(EKS), Emerging Technologies, Kubernates, Kubernetes, Orchestrator, PaaS No comments

Introduction: Amazon Elastic Kubernetes Service (EKS) simplifies the process of deploying, managing, and scaling containerized applications using Kubernetes on AWS. In this guide, we’ll explore how to provision an AWS EKS cluster using Terraform, an Infrastructure as Code (IaC) tool. We’ll cover essential concepts, Terraform configurations, and provide hands-on examples to help you get started with deploying EKS clusters efficiently.

Understanding AWS EKS: Before diving into the Terraform configurations, let’s familiarize ourselves with some key concepts related to AWS EKS:

  • Managed Kubernetes Service: EKS is a managed Kubernetes service provided by AWS, which abstracts away the complexities of managing the Kubernetes control plane infrastructure.
  • High Availability and Scalability: EKS ensures high availability and scalability by distributing Kubernetes control plane components across multiple Availability Zones within a region.
  • Integration with AWS Services: EKS seamlessly integrates with other AWS services like Elastic Load Balancing (ELB), Identity and Access Management (IAM), and Amazon ECR, simplifying the deployment and operation of containerized applications.

Provisioning AWS EKS with Terraform: Now, let’s walk through the steps to provision an AWS EKS cluster using Terraform:

  1. Setting Up Terraform Environment: Ensure you have Terraform installed on your system. You can download it from the official Terraform website or use a package manager.
  2. Initializing Terraform Configuration: Create a new directory for your Terraform project and initialize it with a main.tf file. Inside main.tf, add the following configuration:
provider "aws" {
  region = "your-preferred-region"
}

module "eks_cluster" {
  source  = "terraform-aws-modules/eks/aws"
  version = "X.X.X"  // Use the latest version

  cluster_name    = "my-eks-cluster"
  cluster_version = "1.21"
  subnets         = ["subnet-1", "subnet-2"] // Specify your subnets
  # Additional configuration options can be added here
}

Replace "your-preferred-region", "my-eks-cluster", and "subnet-1", "subnet-2" with your desired AWS region, cluster name, and subnets respectively.

3. Initializing Terraform: Run terraform init in your project directory to initialize Terraform and download the necessary providers and modules.

4. Creating the EKS Cluster: After initialization, run terraform apply to create the EKS cluster based on the configuration defined in main.tf.

5. Accessing the EKS Cluster: Once the cluster is created, Terraform will provide the necessary output, including the endpoint URL and credentials for accessing the cluster.

IAM Policies and Permissions: To interact with the EKS cluster and underlying resources, you need to configure IAM policies and permissions.

Here’s a basic IAM policy that grants necessary permissions for managing EKS clusters, EC2 and S3 related resources:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "eks:*",
      "Resource": "*"
    },
    {
       "Effect": "Allow",
       "Action": "ec2:*",
       "Resource": "*"
    },
    {
       "Effect": "Allow",
       "Action": "s3:*",
       "Resource": "*"
    },
    {
       "Effect": "Allow",
       "Action": "iam:*",
       "Resource": "*"
    }
   
  ]
}

Make sure to attach this policy to the IAM role or user that Terraform uses to provision resources.

Conclusion: In this guide, I’ve covered the process of provisioning an AWS EKS cluster using Terraform, along with essential concepts and best practices. By following these steps and leveraging Terraform’s infrastructure automation capabilities, you can streamline the deployment and management of Kubernetes clusters on AWS. Experiment with different configurations and integrations to tailor your EKS setup according to your specific requirements and workload characteristics. Happy clustering!

Additional References:

  1. AWS EKS Documentation – Official documentation providing in-depth information about Amazon EKS, including getting started guides, best practices, and advanced topics.
  2. Terraform AWS EKS Module – Official Terraform module for provisioning AWS EKS clusters. This module simplifies the process of setting up EKS clusters using Terraform.
  3. IAM Policies for Amazon EKS – Documentation providing examples of IAM policies for Amazon EKS, helping you define fine-grained access controls for EKS clusters and resources.
  4. Kubernetes Documentation – Official Kubernetes documentation offering comprehensive guides, tutorials, and references for learning Kubernetes concepts and best practices.

Private Kubernetes cluster in AKS with Azure Private Link

March 13, 2023 Azure, Azure, Azure CLI, Azure Cloud Shell, Best Practices, Cloud Computing, Cloud Native, Kubernetes, Managed Services, Microsoft, PaaS No comments

Today, we’ll take a look at a new feature in AKS called Azure Private Link, which allows you to connect to AKS securely and privately over the Microsoft Azure backbone network.

In the past, connecting to AKS from an on-premises network or other virtual network required using a public IP address, which posed potential security risks. With Azure Private Link, you can now connect to AKS over a private, dedicated connection within the Azure network, reducing the surface area for potential security threats.

How Azure Private Link works

Azure Private Link works by providing a private endpoint for your AKS cluster, which is essentially a private IP address within your virtual network. You can then configure your virtual network to allow traffic to the private endpoint, which is connected to AKS through the Azure backbone network.

When you create a private endpoint for your AKS cluster, a network interface is created in your virtual network. You can then configure your network security groups to allow traffic to the private endpoint, and create a private DNS zone to resolve the private endpoint’s DNS name.

Benefits of using Azure Private Link with AKS

Here are a few key benefits of using Azure Private Link with AKS:

Enhanced Security

Connecting to AKS over a private, dedicated connection within the Azure network can significantly reduce the surface area for potential security threats. This helps ensure that your AKS cluster is only accessible to authorized users and services.

Improved Network Performance

Azure Private Link offers fast, reliable connectivity to your AKS cluster, with low latency and high throughput. This can help improve the performance of your applications and services running on AKS.

Simplified Network Configuration

Using Azure Private Link to connect to AKS eliminates the need for complex network configurations, such as setting up VPNs or firewall rules. This can help simplify your network architecture and reduce the time and resources required for configuration and maintenance.

Getting Started with Azure Private Link for AKS

To get started with Azure Private Link for AKS, you’ll need to have an AKS cluster and a virtual network in your Azure subscription. You can then follow these high-level steps:

  1. Create a private endpoint for your AKS cluster.
  2. Configure your virtual network to allow traffic to the private endpoint.
  3. Create a private DNS zone to resolve the private endpoint’s DNS name.
  4. Connect to your AKS cluster using the private endpoint.

Here are a few examples for setting up Azure Private Link for AKS using the Azure CLI and Terraform:

Azure CLI Example

Here’s an example of how to create a private endpoint for an AKS cluster using the Azure CLI:

#Azure CLI# Set variables for resource names and IDs
AKS_RESOURCE_GROUP=myAKSResourceGroup
AKS_CLUSTER_NAME=myAKSCluster
VNET_NAME=myVirtualNetwork
SUBNET_NAME=mySubnet
PRIVATE_DNS_ZONE_NAME=myPrivateDNSZone
PRIVATE_ENDPOINT_NAME=myAKSPrivateEndpoint
PRIVATE_ENDPOINT_GROUP_NAME=myAKSPrivateEndpointGroup

# Create a private endpoint for the AKS cluster
az network private-endpoint create \
  --name $PRIVATE_ENDPOINT_NAME \
  --resource-group $AKS_RESOURCE_GROUP \
  --vnet-name $VNET_NAME \
  --subnet $SUBNET_NAME \
  --private-connection-resource-id "/subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.ContainerService/managedClusters/{aks-cluster-name}" \
  --group-id $PRIVATE_ENDPOINT_GROUP_NAME \
  --connection-name $PRIVATE_ENDPOINT_NAME-conn \
  --location northeurope \
  --dns-name $PRIVATE_DNS_ZONE_NAME.privatelink.azure.com
In this example, we're creating a private endpoint for an AKS cluster named "myAKSCluster" in a virtual network named "myVirtualNetwork". We're also creating a private DNS zone named "myPrivateDNSZone" and specifying a connection name of "myAKSPrivateEndpoint-conn".

Terraform Example

Here’s an example of how to create a private endpoint for an AKS cluster using Terraform:

#hcl-terraform# Set variables for resource names and IDs
variable "resource_group_name" {}
variable "aks_cluster_name" {}
variable "virtual_network_name" {}
variable "subnet_name" {}
variable "private_dns_zone_name" {}
variable "private_endpoint_name" {}
variable "private_endpoint_group_name" {}

# Create a private endpoint for the AKS cluster
resource "azurerm_network_private_endpoint" "aks_endpoint" {
  name                = var.private_endpoint_name
  location            = "eastus"
  resource_group_name = var.resource_group_name
  subnet_id           = azurerm_subnet.aks.id

  private_service_connection {
    name                          = "${var.private_endpoint_name}-conn"
    private_connection_resource_id = "/subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.ContainerService/managedClusters/${var.aks_cluster_name}"
    group_ids                     = [var.private_endpoint_group_name]
  }

  custom_dns_config {
    fqdn            = "${var.private_dns_zone_name}.privatelink.azure.com"
    ip_addresses    = azurerm_private_endpoint_dns_zone_group.aks_dns_zone_group.ip_addresses
    private_zone_id = azurerm_private_dns_zone.aks_dns_zone.id
  }
}
In this example, we're creating a private endpoint for an AKS cluster named "myAKSCluster" in a virtual network named "myVirtualNetwork". We're also creating a private DNS zone named "myPrivateDNSZone" and specifying a connection name of "myAKSPrivateEndpoint-conn".

Detailed instructions for setting up Azure Private Link for AKS can be found in the Microsoft Azure documentation.

In Summary: Azure Private Link is a powerful new feature in AKS that allows you to connect to your AKS cluster securely and privately over the Azure backbone network. By reducing the surface area for potential security threats and improving network performance, Azure Private Link can help ensure that your AKS workloads are secure, performant, and easy to manage. If you haven’t yet tried out Azure Private Link with AKS, now is a great time to get started!

Difference between workload managed identity, Pod Managed Identity and AKS Managed Identity

March 12, 2023 Azure, Azure, Azure Kubernetes Service(AKS), Cloud Computing, Cloud Native, Cloud Strategy, Computing, Emerging Technologies, Intelligent Cloud, Kubernetes, Managed Services, Microsoft, PaaS, Platforms No comments

Azure Kubernetes Service(AKS) offers several options for managing identities within Kubernetes clusters, including AKS Managed Identity, Pod Managed Identity, and Workload Managed Identity. Here’s a comparison of these three options:

Key FeaturesAKS Managed IdentityPod Managed IdentityWorkload Managed Identity
OverviewA built-in feature of AKS that allows you to assign an Azure AD identity to your entire clusterAllows you to assign an Azure AD identity to an individual podAllows you to assign an Azure AD identity to a Kubernetes workload, which can represent one or more pods
ScopeCluster-widePod-specificWorkload-specific
Identity TypeService PrincipalManaged Service IdentityManaged Service Identity
Identity LocationClusterNodeNode
UsageGenerally used for cluster-wide permissions, such as managing Azure resourcesUseful for individual pod permissions, such as accessing Azure Key Vault secretsUseful for workload-specific permissions, such as accessing a database
LimitationsLimited to one identity per clusterLimited to one identity per podNone
Configuration ComplexityRequires configuration of AKS cluster and Azure ADRequires configuration of individual pods and Azure ADRequires configuration of Kubernetes workloads and Azure AD
Key features Comparison Table

Here are a few examples of how you might use each type of identity in AKS:

AKS Managed Identity

Suppose you have an AKS cluster that needs to access Azure resources, such as an Azure Key Vault or Azure Storage account. You can use AKS Managed Identity to assign an Azure AD identity to your entire cluster, and then grant that identity permissions to access the Azure resources. This way, you don’t need to manage individual service principals or access tokens for each pod.

Pod Managed Identity

Suppose you have a pod in your AKS cluster that needs to access a secret in Azure Key Vault. You can use Pod Managed Identity to assign an Azure AD identity to the pod, and then grant that identity permissions to access the secret in Azure Key Vault. This way, you don’t need to manage a separate service principal for the pod, and you can ensure that the pod only has access to the resources it needs.

Workload Managed Identity

Suppose you have a Kubernetes workload in your AKS cluster that needs to access a database hosted in Azure. You can use Workload Managed Identity to assign an Azure AD identity to the workload, and then grant that identity permissions to access the database. This way, you can ensure that the workload only has access to the database, and you don’t need to manage a separate service principal for each pod in the workload.

In summary, each type of AKS identity has its own strengths and use cases. AKS Managed Identity is useful for cluster-wide permissions, Pod Managed Identity is useful for individual pod permissions, and Workload Managed Identity is useful for workload-specific permissions. By choosing the right type of identity for your needs, you can simplify identity management and ensure that your AKS workloads have secure and controlled access to Azure resources.

How is AKS workload identity different from AKS pod managed identity?

March 12, 2023 Azure, Azure, Azure Kubernetes Service(AKS), Cloud Computing, Cloud Native, Cloud Strategy, Kubernetes, Managed Services, Microsoft, PaaS, Platforms No comments

AKS workload identity and AKS pod managed identity both provide a way to manage access to Azure resources from within a Kubernetes cluster. However, there are some key differences between the two features.

Scope

AKS pod managed identity provides a managed identity for each individual pod within a Kubernetes cluster. This allows you to grant access to Azure resources at a very granular level. AKS workload identity, on the other hand, provides a single AAD service principal for a Kubernetes namespace. This provides a broader scope for access to Azure resources within the namespace.

Access management

With AKS pod managed identity, you can assign roles or permissions directly to individual pods. This provides greater flexibility for managing access to Azure resources within the cluster. With AKS workload identity, access management is done through AAD roles and role assignments. This provides a more centralized approach to managing access to Azure resources within the namespace.

Security

AKS pod managed identity eliminates the need to store secrets or access tokens within pod configurations, which can improve the security of the Kubernetes cluster. AKS workload identity also eliminates the need to store secrets or access tokens within pod configurations. However, because the AAD service principal is shared by all pods within the namespace, there is a risk that if the service principal is compromised, all pods within the namespace could be affected.

In summary, AKS workload identity is a powerful feature of AKS that enables you to use Azure Active Directory to manage access to Azure resources from within a Kubernetes cluster. By creating a single AAD service principal for a Kubernetes namespace, AKS workload identity provides a centralized approach to access management. This can simplify the management of access to Azure resources and improve the security of your Kubernetes cluster.

While AKS pod managed identity and AKS workload identity both provide a way to manage access to Azure resources from within a Kubernetes cluster, they have different scopes and approaches to access management. By understanding the differences between the two features, you can choose the approach that best meets the needs of your organization.

AKS pod managed identity

March 12, 2023 Azure, Azure, Azure Kubernetes Service(AKS), Cloud Computing, Cloud Native, Kubernetes, Managed Services, PaaS, Platforms No comments

Kubernetes has become one of the most popular container orchestration tools, and Azure Kubernetes Service (AKS) is a managed Kubernetes service provided by Microsoft Azure. With the increasing use of Kubernetes and AKS, there is a growing need to improve the security and management of access to cloud resources.

AKS pod managed identity is a feature of AKS that simplifies the management of access to Azure resources by creating an identity for each pod in a Kubernetes cluster. The AKS pod managed identity allows the pods to access Azure services securely without the need to manage credentials, passwords, or access tokens.

In this blog post, we’ll take a closer look at what AKS pod managed identity is, how it works, and its benefits.

What is AKS Pod Managed Identity?

AKS pod managed identity is a feature of AKS that enables the management of identities for pods in a Kubernetes cluster. When a pod is created with AKS pod managed identity enabled, a Managed Identity is automatically created for that pod. This Managed Identity is then used to authenticate the pod with Azure services such as Azure Key Vault, Azure Storage, and Azure SQL Database, among others.

AKS pod managed identity eliminates the need for storing secrets and credentials within the pod’s configuration, which can improve the security of the pod and simplify the management of access to cloud resources.

How AKS Pod Managed Identity Works

AKS pod managed identity uses Azure’s Managed Identity service, which is a feature of Azure Active Directory (AAD). When a pod is created in an AKS cluster with pod managed identity enabled, a Managed Identity is automatically created for that pod.

To use AKS pod managed identity, you must first enable the feature in your AKS cluster. This can be done using the Azure CLI or through the Azure portal. Once enabled, you can then create a Kubernetes manifest file that includes a ManagedIdentity resource definition for each pod that needs to access Azure resources.

Here’s an example of a Kubernetes manifest file that uses AKS pod managed identity:

#yaml 
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    env:
    - name: AZURE_TENANT_ID
      value: "<tenant-id>"
    - name: AZURE_CLIENT_ID
      value: "<client-id>"
    - name: AZURE_CLIENT_SECRET
      valueFrom:
        secretKeyRef:
          name: my-secret
          key: my-secret-key
  identity:
    type: ManagedIdentity

In this example, the identity section defines a Managed Identity for the pod using the type: ManagedIdentity field. The AZURE_TENANT_ID, AZURE_CLIENT_ID, and AZURE_CLIENT_SECRET environment variables are also defined, which allow the pod to authenticate with Azure services using its Managed Identity.

Once the pod is created, you can then grant it access to Azure resources by assigning it the appropriate role or permissions. This can be done using Azure’s Role-Based Access Control (RBAC) system or through other access control mechanisms provided by Azure services.

Here’s another example manifest file that demonstrates how to use AKS Pod Managed Identity:

#yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: myregistry/my-app:v1
        ports:
        - containerPort: 80
        env:
        - name: AzureServicesAuthConnectionString
          value: RunAs=App;AppId=<app-id>;TenantId=<tenant-id>;AppKey=<app-key>
      identity:
        type: ManagedIdentity

In this example, the identity section defines a Managed Identity for the pod using the type: ManagedIdentity field. The AzureServicesAuthConnectionString environment variable is also defined, which allows the pod to authenticate with Azure services using its Managed Identity.

Once the pod is created, you can then grant it access to Azure resources by assigning it the appropriate role or permissions. This can be done using Azure’s Role-Based Access Control (RBAC) system or through other access control mechanisms provided by Azure services.

Benefits of AKS Pod Managed Identity

AKS pod managed identity provides several benefits, including:

Improved security

AKS pod managed identity eliminates the need to store credentials or access tokens within the pod’s configuration. This reduces the risk of accidental exposure of sensitive data and improves the overall security of the pod and the cluster.

Simplified management

AKS pod managed identity simplifies the management of access to cloud resources by creating an identity for each pod in a Kubernetes cluster. This eliminates the need to manage service principals or credentials manually, which can reduce the administrative overhead and improve the efficiency of the cluster.

Greater flexibility

AKS pod managed identity provides greater flexibility by allowing you to grant access to Azure resources at a more granular level. You can assign roles or permissions directly to individual pods, which can reduce the risk of unauthorized access and improve the overall security posture of the cluster.

Easier compliance

AKS pod managed identity can make it easier to comply with regulatory requirements such as GDPR, HIPAA, and PCI DSS. By eliminating the need to store secrets and credentials within the pod’s configuration, you can reduce the risk of non-compliance and simplify the auditing process.

Better scalability

AKS pod managed identity can help improve the scalability of your Kubernetes clusters by reducing the overhead associated with managing service principals or credentials manually. This can enable you to scale your clusters more easily and efficiently, which can improve the overall performance and availability of your applications.

Conclusion

AKS pod managed identity is a powerful feature of AKS that can simplify the management of access to Azure resources, improve the security of your pods and clusters, and help you comply with regulatory requirements. By creating a Managed Identity for each pod in your Kubernetes cluster, AKS pod managed identity can eliminate the need to manage credentials and access tokens manually, which can reduce the administrative overhead and improve the efficiency of your operations.

In addition to AKS pod managed identity, Azure provides other identity and access management features such as AKS managed identity and workload management identity that can help you manage access to your Azure resources securely. By using these features in conjunction with AKS pod managed identity, you can create a comprehensive identity and access management solution for your Kubernetes workloads in Azure.

References

  • Use Azure Active Directory pod-managed identities in Azure Kubernetes Service (Preview)

AKS Workload Identity

March 11, 2023 Azure, Azure, Azure Kubernetes Service(AKS), Cloud Computing, Cloud Native, Computing, Intelligent Cloud, Kubernetes, Managed Services, Microsoft, PaaS, Platforms No comments

AKS workload identity is a feature of Azure Kubernetes Service (AKS) that enables you to use Azure Active Directory (AAD) to manage access to Azure resources from within a Kubernetes cluster. In this blog post, we’ll explore how AKS workload identity works and how to use it with an example code.

How does AKS workload identity work?

AKS workload identity works by creating an AAD service principal that is associated with a Kubernetes namespace. This service principal can be used by pods within the namespace to access Azure resources, such as storage accounts, without needing to store secrets or access tokens within the pod configuration.

When a pod needs to access an Azure resource, it sends a request to the Kubernetes API server, which forwards the request to the Azure Identity Binding Controller. The controller then looks up the AAD service principal associated with the namespace and retrieves an access token from AAD on behalf of the pod. This access token is then used to authenticate the pod to the Azure resource.

How to use AKS workload identity

To use AKS workload identity, you need to have an Azure subscription, an AKS cluster, and an AAD tenant. Here are the steps to set up AKS workload identity and use it in your application:

1. Create an AAD application registration

First, you need to create an AAD application registration for your AKS cluster. This application registration will be used to create the service principal that is associated with your Kubernetes namespace.

You can create an application registration by following these steps:

  1. Go to the Azure portal and navigate to your AAD tenant.
  2. Click on “App registrations” and then click on “New registration”.
  3. Give your application a name and select “Accounts in this organizational directory only” for the supported account types.
  4. Under “Redirect URI (optional)”, select “Web” and enter a dummy URI.
  5. Click on “Register”.

Make a note of the “Application (client) ID” and “Directory (tenant) ID” for later use.

2. Grant permissions to the AAD application registration

Next, you need to grant permissions to the AAD application registration to access the Azure resources that you want to use in your application.

You can grant permissions by following these steps:

  1. Go to the Azure portal and navigate to the resource that you want to grant access to.
  2. Click on “Access control (IAM)” and then click on “Add role assignment”.
  3. Select the role that you want to assign and then search for the name of your AAD application registration.
  4. Select your AAD application registration from the list and then click on “Save”.

3. Create a Kubernetes namespace with AKS workload identity enabled

Next, you need to create a Kubernetes namespace with AKS workload identity enabled. This namespace will be associated with the AAD service principal that you created in step 1.

You can create a namespace with AKS workload identity enabled by following these steps:

  1. Create a Kubernetes namespace with the following annotations:
#yaml code
apiVersion: v1
kind: Namespace
metadata:
  name: <your-namespace-name>
  annotations:
    "aadpodidentitybinding": "binding-name"
  1. Create an AKS identity binding with the following annotations:
#yaml codeapiVersion: aadpodidentity.k8s.io/v1
kind: AzureIdentityBinding
metadata:
  name: binding-name
spec:
  azureIdentity: <your-azure-identity>
  selector: <your-selector>

4. Use AKS workload identity in your application

Finally, you can use AKS workload identity in your application by configuring your application to use the service principal associated with your Kubernetes namespace.

Here’s an example code snippet in C# that demonstrates how to use AKS workload identity with the Azure SDK for .NET:

#csharp code
using System;
using System.Threading.Tasks;
using Microsoft.Azure.Storage;
using Microsoft.Azure.Storage.Blob;
using Microsoft.Azure.Services.AppAuthentication;

namespace AKSWorkloadIdentityExample
{
    class Program
    {
        static async Task Main(string[] args)
        {
            // create a new instance of AzureServiceTokenProvider
            var tokenProvider = new AzureServiceTokenProvider();

            // create a new instance of CloudStorageAccount using the AKS identity endpoint
            var storageAccount = new CloudStorageAccount(new Microsoft.Azure.Storage.Auth.TokenCredentialAdapter(tokenProvider), "<your-storage-account-name>", endpointSuffix: null, useHttps: true);

            // create a new instance of CloudBlobClient using the CloudStorageAccount
            var blobClient = storageAccount.CreateCloudBlobClient();

            // use the CloudBlobClient to retrieve the contents of a blob
            var container = blobClient.GetContainerReference("<your-container-name>");
            var blob = container.GetBlockBlobReference("<your-blob-name>");
            var contents = await blob.DownloadTextAsync();

            Console.WriteLine(contents);
        }
    }
}

In this example, we create a new instance of AzureServiceTokenProvider, which uses the AKS identity endpoint to retrieve an access token for the AAD service principal associated with the Kubernetes namespace. We then use this token provider to create a new instance of CloudStorageAccount, passing in the name of the storage account we want to access.

Next, we create a new instance of CloudBlobClient using the CloudStorageAccount, and use it to retrieve the contents of a blob. Note that we don’t need to pass any secrets or access tokens to the CloudBlobClient. Instead, the AKS identity endpoint handles authentication on our behalf, making it much easier to manage access to Azure resources from within our Kubernetes cluster.

I hope this example helps you understand how to use AKS workload identity with the Azure SDK for .NET!

Conclusion

AKS workload identity is a powerful feature of AKS that enables you to use AAD to manage access to Azure resources from within your Kubernetes cluster. By using AKS workload identity, you can avoid storing secrets or access tokens within your pod configurations, making it easier to manage security and access control in your application.

In this blog post, we’ve explored how AKS workload identity works and how to use it in your application. We’ve also seen an example code snippet that demonstrates how to use AKS workload identity with the Azure SDK for Go. Hopefully, this has given you a better understanding of how AKS workload identity can be used to simplify access control in your Kubernetes applications.

References