Use managed identity with Bridge to Kubernetes
Note
Microsoft plans to no longer actively maintain the Bridge to Kubernetes project. Over the next few months, we will transition the project to an archival state. In the meantime, the project is still available to use and download. During this period, we hope to explore and recommend community projects that provide similar benefits to Bridge to Kubernetes for your future use. If you have questions, please contact us on our issues board at GitHub.
If your AKS cluster uses managed identity security features to secure access to secrets and resources, Bridge to Kubernetes needs some special configuration to ensure it can work with these features. A Microsoft Entra token needs to be downloaded to the local machine to ensure that local execution and debugging is properly secured, and this requires some special configuration in Bridge to Kubernetes. This article shows how to configure Bridge to Kubernetes to work with services that use managed identity.
How to configure your service to use managed identity
To enable a local machine with support for managed identity, in the KubernetesLocalConfig.yaml file, in the enableFeatures section, add ManagedIdentity. Add the enableFeatures section if it's not already there.
enableFeatures:
- ManagedIdentity
Warning
Be sure to only use managed identity for Bridge to Kubernetes when working with dev clusters, not production clusters, because the Microsoft Entra token is fetched to the local machine, which presents a potential security risk.
If you don't have a KubernetesLocalConfig.yaml file, you can create one; see How to: Configure Bridge to Kubernetes.
How to fetch the Microsoft Entra tokens
You must ensure that you are relying on either Azure.Identity.DefaultAzureCredential or Azure.Identity.ManagedIdentityCredential in code when fetching the token.
The following C# code shows how to fetch storage account credentials when you use ManagedIdentityCredential:
var credential = new ManagedIdentityCredential(miClientId);
Console.WriteLine("Created credential");
var containerClient = new BlobContainerClient(new Uri($"https://{accountName}.blob.windows.net/{containerName}"), credential);
Console.WriteLine("Created blob client");
The following code shows how to fetch storage account credentials when you use DefaultAzureCredential:
var credential = new DefaultAzureCredential();
Console.WriteLine("Created credential");
var containerClient = new BlobContainerClient(new Uri($"https://{accountName}.blob.windows.net/{containerName}"), credential);
Console.WriteLine("Created blob client");
To learn how to access other Azure resources using managed identity, see the Next steps section.
Receive Azure alerts when tokens are downloaded
Whenever you use Bridge to Kubernetes on a service, the Microsoft Entra token is downloaded to the local machine. You can enable Azure alerts to be notified when this occurs. For information, see Enable Azure Defender. Please be aware that there is a charge (after a 30-day trial period).
Next steps
Now that you've configured Bridge to Kubernetes to work with your AKS cluster that uses managed identity, you can debug as normal. See [bridge-to-kubernetes.md#connect-to-your-cluster-and-debug-a-service].
Learn more about using managed identify to access Azure resources by following these tutorials:
- Tutorial: Use a Linux VM system-assigned managed identity to access Azure Storage
- Tutorial: Use a Linux VM system-assigned managed identity to access Azure Data Lake Store
- Tutorial: Use a Linux VM system-assigned managed identity to access Azure Key Vault
There are other tutorials in that section as well for using managed identity to access other Azure resources.