A common and on-going challenge for teams is how to manage their sensitive credentials like DB connection strings, Storage Keys and etc... And the market is not in short of tools that can help to store and retrieve these secrets. tools like AWS Secret Manager, HashiCorp KeyVault, Azure Key Vault.
But even with this nice tools governing these systems and putting best practices around how developers and app retrieve these credentials and rotating them on a regular basis is a challenge that has no silver bullet for it. Managed Identity comes handy to eliminate the needs for developers to manage/rotate credentials any longer.
The current situation at my client: In the current team I am working the application relies heavily on SQL Server that is hosted in Azure SQ. Both Developers in their local environment as well as the App running in Azure AKS are accessing SQL DB via the conventional Connection String that consist of Username and Password. we have created a new SQL user for each developer to access the DEV DB, and all of the applications are using a Shared credentials to access the Database. Managing the SQL users and protecting and rotating those shared credentials has felt like a task that nobody enjoyed dealing with.
To give you a bit of perspective this is how the current connection string looks like for one of our DotNet Core Apps:
And below is the new Connection String format that utilises Managed Identity:
As you can see the new Connection String does not contain any Username and Password but then it is able to connect to Azure Active Directory and retrieve a token from there using my Azure AD account and use that token to authenticate to Azure SQL. how it know which AD account it should use comes from the fact that I am logged in to
Visual Studio using my AD Account and it uses the account that im currently logged in to Visual Studio by default.
But hold on, how this is going to work when we run this as a Pod in Kubernetes (AKS)? this is where
Azure Pod Identity comes to picture. Azure Pod Identity uses Azure Active Directory as the Identity provider to authenticate the running Pod against different Azure Services such as Azure SQL, Azure Cosmos, Azure Storage, etc...
To get started we need to first create Identity object in the same resource group where the AKS is deployed. ( refer to MS link I shared above for the how to part of creating identity) once the identity is created we then need to assign permission to it in my use case I give READ/Write permission to the SQL DB I wanted to authenticate towards.
The last piece of puzzle is to add a new label to our Deployment file that select the identity you created. The label is aadpodidbinding and the value for it is the name of the identity you created.
Here is the sample of the deployment file I took from MS example:
My personal reflection after using Azure Identity with AKS
As I mentioned earlier managing secrets is always a major security challenge for any application and using Azure Identity to connect your Pods into other Services like SQL seem to be a considerable solution to get rid of managing and rotating Secrets and Credentials with that being said like everything else in life, Azure Identity comes with overhead. From my personal experience introducing Azure Identity introduces additional complexity into your workload and makes debugging your app harder than it already was.
Also according to Microsoft official document, Azure Identity is currently in preview. so don't rush into introducing it in to our production workload. make sure you test this enough and throughly in your non-critical environment first.
Comments
Post a Comment