Azure AD Authentication for AKS does not support service principals. Here is how you can still use automation and CI/CD against a cluster that is using AAD.
This week we saw the announcement of the public preview of Windows Server Containers on Azure Kubernetes Service (AKS). Windows support in AKS has been something we’ve been waiting for, for a while now and is excellent news for those trying to lift and shift Windows applications into containers. As we’ve discussed previously, if you can, using Linux containers is always going to give you the fastest start-up time and fewer complications, however not everyone can re-write their apps in .
When you deploy a service in AKS that is of type load balancer, or you create an Ingress, AKS will automatically create an NSG rule for you . This rule is applied to the NSG that is attached to your nodes NICs and will open up your services port to “All”. If your planning on publishing your application to be accessed by anyone then this is fine. However, if you want to lock access to your application down to specific users then this can be a bit of a pain.
Prometheus has become the default metrics collection mechanism for use in a Kubernetes cluster, providing a way to collect the time series metrics for your pods, nodes and clusters. This metric collection allows you to monitor for issues, review performance over time, and also provide metrics to be used by the scaling functionality in Kubernetes. Both the Pod and Cluster auto-scaler can take custom metrics from Prometheus and use these to determine if they can scale out.
If your application is running on a Kubernetes cluster in Azure (AKS, ACS or ACS Engine), then it is likely that you will need to access other Azure resources from your pods that are secured with Azure AD. These operations could include retrieving secrets from Key Vault, files from Blob storage or just interacting with other applications or API’s that use Azure AD as their identity provider. To be able to do this your application needs to be able to provide an identity to access these resources securely.
In any application it is likely you are going to need access to some “secret” data, connection strings, API keys, passwords etc. It is essential that the applications that need them can access these secrets, but that they are also kept secure. One way of doing this is using Azure Keyvault; this is a secure store which can hold secrets, keys and certificates and allow applications to access them securely. Generally, Keyvault Secrets are accessed by the application making a call to the KeyVault API and providing the appropriate credentials (username/password, certificate or managed service identity).