Intelligent Cloud

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.

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

Azure in China

May 17, 2017 .NET, AppFabric, Azure, Azure In China, Azure IoT Suite, Cloud Computing, Cloud Services, IaaS, Intelligent Cloud, Intelligent Edge, IoT Hub, Media Services, Microsoft, Mobile Services, PaaS, SQL Azure, SQL Server, VisualStudio, Windowz Azure 1 comment

Microsoft Azure presence in China is always a question when there is a need for any customer to deploy azure applications specifically for Chinese Regional customers.

Recently I had an interaction with a Microsoft Certified Trainer, who carelessly said Azure only uses Chinese partner based environment is only for serving CDN (Content Delivery Network) needs, partial knowledge is difficult to convince. Being a Certified Trainer, he should have known these. As I recollect my earlier experience with azure, I was aware that Microsoft has partnered with 21Vianet , to setup a Chinese instance of Azure with most possible IaaS, PaaS and SaaS offerings are available to Chinese customers. At the same time data would reside within Chinese governments data privacy and storage regulations.

Similarly other competitor cloud providers such as IBM also partnered with 21Vianet to setup their BlueMix instances in China.

Microsoft Azure in China

General availability of Azure in China through 21vianet partnership has been announced in March 26th 2014. These Azure Services in Chinese region will be operated and sold by 21vianet.

Quoting to Doug Hauger GM- National Cloud Programs, Microsoft

Windows Azure, operated by 21Vianet, is based on the same technology as Microsoft’s global Windows Azure service and offers a reliable, flexible and value-based service to bring Microsoft’s latest cloud technologies and benefits to Chinese customers and propel forward technological development in China as a whole.

Why Partnership?

As per Chinese Government(PRC) Cyber Security Law and Governance policies there is a clear restriction for a foreign entrant to obtain license and provide services to Chinese customers.  All the data relating to Chinese customers should reside within Chinese Data Centres, and foreign companies would have to pass on the operational ownership to a Chinese company in order to operate within PRC(Peoples Republic of China).

In Additional to that on November’2016 new amendments attached to new PRC Cyber Security Law (effective 1st June 2017).

As per DLA PIPER

The new law will come into force on 1 June 2017 and has significant implications for the data privacy and cybersecurity practices of both Chinese companies and international organisations doing business in China.

The new PRC Cybersecurity Law intends to combat online fraud and protect China against Internet security risks. In short, it imposes new security and data protection obligations on “network operators”; puts restrictions on transfers of data outside China by “key information infrastructure operators”; and introduces new restrictions on critical network and cybersecurity products.  [Read more from Source]

Where is Azure in China?

You can access Azure in China instance through a separate portal https://www.azure.cn. Azure Portal is available at https://portal.azure.cn/. Pricing information is available on http://www.azure.cn/pricing/pia/  (click on English to get an English version).

Below are two data centre regions Azure is available in China.

image

Services Offered in Azure China Instances:

Not all all services of Azure including Mobile Services, Analytics and IoT Suite are available for Chinese regions. I will try to cover a specific list of services that are available for China region.Azure China is a few versions behind regular Azure and not all services are supported. Some of the services supported are:

  • Compute – Virtual Machines (For IaaS Services)
  • Compute – Cloud Service (For PaaS Services)
  • Compute – Web Site
  • Data Services – Storage (For Blobs, tables and Queues)
  • Data Services – SQL Database
  • Data Service – HDInsight
  • SQL Database – SQL Import/ExportNetworks – Virtual Network (To communicate between cloud services via Local networks)
  • Service Bus
  • Active Directory
  • Access Control Service – which has its own UI and namespace
  • Caching – only dedicated cache is supported
  • Mobile Service
  • Media Service
  • CDN
  • Traffic Manager
  • Azure IoT Suite
  • Notification Center
  • Event Center
  • Service Fabric
  • Batch Service
  • Flow Analytics, Power BI
  • Document DB, SQL Database, SQL Data Warehouse, MySQL
  • and many more

image

A list of supported and not supported services can be found at (This is in Chinese, and it is a working document, use google translate to take you through all steps necessary for you to understand services offered in Azure China) http://www.windowsazure.cn/documentation/articles/developerdifferences/#readyonwacn

This also includes all the endpoints that are required for developers to integrate/develop applications targeting China region.

Hope this information was helpful to you. I would assume it would be helpful for some who are specifically looking forward for providing technology solutions for Chinese customers through Azure Cloud.

Sources:

Introducing Azure IoT Edge

May 13, 2017 .NET, Analytics, Artificial Intelligence(AI), Augmented Reality, Azure, Azure IoT Suite, Cloud Computing, Data Analytics, Edge Analytics, Embedded, Emerging Technologies, Event Hubs, Industrial Automation, Intelligent Cloud, Intelligent Edge, IoT, IoT Edge, IoT Hub, Linux, Mac OSX, Machine Learning(ML), Microsoft, Robotics, Self Driven Cars, Stream Analytics, Windows, Windowz Azure No comments

During Build! 2017 Microsoft has announced the availability of Azure IoT Edge, which would bring in some of the cloud capabilities to edge devices/networks within your Enterprise. This would enable industrial devices to utilize the capabilities of IoT in Azure within their constrained resources . 

With this Microsoft now makes it easier for developers to move some of their computing needs to these devices.  Edge devices are mostly having small foot print based to high end machines within your company network.

The essential capabilities to be supported by Azure IoT edge  include:

  • Perform Edge Analytics (a cut down version of Azure Stream Analytics)- Instead of doing analytics in cloud developer/implementer can move the basic cloud data processing and analytical capabilities to Edge Device. Run your machine learning algorithms in Edge device and take predictive analytics steps.
  • Perform Artificial Intelligence processing at edge device itself. Availability of Microsoft Cognitive Service on edge device would bring in whole lot of automation capabilities. Imagine Alexa/Siri working without internet connection, it should be able to provide you reminders etc.
  • Perform RealTime Decision making locally based on predefined rules.
  • Reduce bandwidth costs
  • Connect to other Edge devices and legacy devices within the constrained/corporate network.
  • Deploy IoT solutions to Edge Device from Cloud and provide updates as needed.
  • Operate offline without the need of real-time internet connectivity or intermittent connectivity. Doesn’t have to rely on Cloud to provide commands for processing, can do offline data capture and processing of information from other devices connected and take decisions without the need to rely on a connected cloud service.

Azure IoT Edge enables seamless deployment of cloud services such as:

Along with sharing the image represents Azure’s Enterprise Digital Vision, we will discuss about the same in later sessions:

Digital-Enterprise-Vision_png

Getting Started & More information: