Azure

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

Azure Kubernetes Service (AKS) – Managed Identity

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

Azure Kubernetes Service (AKS) is a fully managed Kubernetes container orchestration service provided by Microsoft Azure. It allows users to quickly and easily deploy, manage, and scale containerized applications on Azure. AKS has been a popular choice among developers and DevOps teams for its ease of use and its ability to integrate with other Azure services.

In this blog post, we will explore a new feature that has recently been introduced in AKS – the AKS Managed Identity Preview.

AKS Managed Identity

AKS Managed Identity is a feature that allows AKS clusters to use Azure Managed Identity to authenticate to other Azure services. With this feature, AKS clusters can now use their own identities to access other Azure services, such as Azure Key Vault, Azure Container Registry, and Azure Storage.

Previously, AKS clusters had to use service principals to authenticate to other Azure services. This meant that users had to create a service principal and manually configure it to access Azure resources. This process was time-consuming and error-prone, especially when managing multiple AKS clusters and Azure services.

With AKS Managed Identity, users can now simplify the process of authenticating to Azure services by using the Managed Identity feature of Azure. Managed Identity is a feature that provides an identity for a service or application that is managed by Azure. It eliminates the need for users to manage credentials, such as passwords or keys, by automatically handling the identity and access management tasks.

How AKS Managed Identity works

AKS Managed Identity Preview by creating an Azure Managed Identity for the AKS cluster during the creation process. The Managed Identity is then granted access to the Azure resources that the cluster needs to access.

Once the Managed Identity is created, users can configure the AKS cluster to use it to authenticate to Azure services. This is done by creating a Kubernetes secret that contains the Azure credentials of the Managed Identity.

The AKS cluster can then use the Kubernetes secret to authenticate to Azure services, such as Azure Key Vault, Azure Container Registry, and Azure Storage.

Benefits of AKS Managed Identity

AKS Managed Identity provides several benefits for users, including:

  1. Simplified authentication: AKS clusters can now use their own identities to authenticate to Azure services, eliminating the need for users to create and manage service principals.
  2. Improved security: Managed identities are a more secure way of authenticating to Azure services, as they eliminate the need for users to store and manage secrets such as passwords or keys.
  3. Reduced management overhead: With AKS Managed Identity Preview, users no longer need to manually configure service principals to access Azure services. This reduces management overhead and ensures that AKS clusters are always using the correct credentials.
  4. Better integration with other Azure services: AKS Managed Identity Preview allows AKS clusters to integrate more seamlessly with other Azure services, such as Azure Key Vault, Azure Container Registry, and Azure Storage.

What are Managed Identities?

Managed identities are essentially a wrapper around service principals, and make their management simpler.
Managed identities use certificate-based authentication, and each managed identities credential has an expiration of 90 days and it’s rolled after 45 days.
AKS uses both system-assigned and user-assigned managed identity types, and these identities are immutable.

Conclusion

AKS Managed Identity is a feature that provides a simpler and more secure way of authenticating AKS clusters to Azure services. By using Managed Identity, users can eliminate the need for service principals and simplify the process of managing Azure resources. AKS Managed Identity Preview also provides improved security and better integration with other Azure services, making it a valuable addition to the AKS feature set.

References

Read Use a managed identity in Azure Kubernetes Service from Microsoft Learn for more details

Azure Cosmos DB – TTL (Time to Live) – Reference Usecase

October 9, 2018 .NET, .NET Core, .NET Framework, Analytics, Architecture, Azure, Azure, Azure Cosmos DB, Azure Functions, Azure IoT Suite, Cloud Computing, Cold Path Analytics, CosmosDB, Emerging Technologies, Hot Path Analytics, Intelligent Cloud, Intelligent Edge, IoT Edge, IoT Hub, Microsoft, Realtime Analytics, Visual Studio 2017, VisualStudio, VS2017, Windows No comments

TTL capability within Azure Cosmos DB is a live saver, as it would take necessary steps to purge redudent data based on the configurations you may. 

Let us think in terms of an Industrial IoT scenario, devices can produce vast amounts of telemetry information, logs and user session information that is only useful until we operate on them and take action on them, to be specific up to finate period of time. Once that data becomes surplus, we need an application logic that purges these old records.

With the “Time to Live” or TTL, Microsoft Cosmos DB provides an ability to have your documents automatically purged from database storage after a certian period if time(which you configured)

  • This TTL by default can be set on a document collection level and later can be overridden on a per document basis.
  • Once the TTL is set, Cosmos DB service will automatically remove the documents when its lifetime is over.
  • Inorder to track TTL, Cosmos DB uses an offset field to check when it was last modified.  This field is identifiable as “_ts”, which exists in every document you create.  Basically it is a UNIX epoch timestamp. This field is updated everytime when the document is modified. [Ref: Picture1]

image

[Picture1]

Enabling TTL on Cosmos DB Collection:

You can enable TTL on a Cosmos DB collection simply by using Azure Portal –> Cosmos DB collection setting for existing or during creation of  a new collection)

TTL value needs to be set in seconds – if you need 90 days => 60 sec * 60 min * 24 hour * 90 days = 7776000 seconds

image

[Picture2]

Below is a one of the reference architecture in which Cosmos DB – TTL would be essentially useful and viable to any Iot business case:

image

[Picture3]

Hope that was helpful to get some understanding. For more references visit:  Cosmos DB Documentation