This post has been republished via RSS; it originally appeared at: Core Infrastructure and Security Blog articles.
In the last blog we discussed AKS Pod Identity and how we utilize this feature in our application and establish a secure access to Azure resources using Azure SDK libraries. One of disadvantage of using Pod Identity is in case of existing workload that use K8s secrets. If developer wants to adapt pod Identity instead of using K8s secrets, then developer will need to refactor the existing code and add Azure Key Vault libraries to retrieve secrets from KV.
Now this considers a blocker for customer with existing workload that depends on K8s secrets. By using Secret Store CSI Driver feature we can unblock customers and help them to moving their workload faster to AKS.
What is Secret Store CSI Driver?
Using the pod identity feature enables authentication against supporting Azure services. When applications need a credential, they communicate with the digital vault, retrieve the latest secret contents, and then connect to the required service. Azure Key Vault can be this digital vault. The simplified workflow for retrieving a credential from Azure Key Vault using pod managed identities is shown in the following diagram:
You can review Microsoft docs about secret provider and Pod security best practice here
How to use secret provider CSI ?
In order to use secret provider in our code we will need AKS cluster to be configured with Azure AAD and Pod Identity and Secret Store CSI driver deployed as we discussed in our pervious posts. The following chart summarize the steps
In our demo today, we will show how to create a pod with the “secret provider class” object mounted as a volume. You can find the code here
Helm Chart Review
The helm chart will be the same chart for all demos (java/C#/Python) we will override the values.yaml during the pipeline run to fit every demo needs. The chart will deploy the following:
- Applications pods deployment: we can control how many replica from values.yaml
- Service deployment:
- Ingress deployment: map incoming request to app services
Same like last post there will be a metadata label aadpodbinding. The pod deployment file MUST have this label. In our environment we deployed the AzureIdentity and AzureIdentityBinding with same name like environment namespace hence we passing the namespace as value for aadpodbinding.
To enable Secret Store CSI driver we will need to add Volume.
You will notice in this demo we are passing the namespace as a name for secretProviderClass. During the first post we established the secretProviderClass object and name it as namespace.
After adding the volume, we will need to mount the volume to pod
One the great advantage of this feature is the ability to generate a K8s secrets beside mounting the secrets to pod. So the app can get the secret from the volume or use the traditional way to get secrets as environment variables.
In our demo we will be passing an environment variable call “COSMOS_DB_KEY”
You will notice when we created the cluster and generated the secret store object we did assign value “cosmosdbkey” to secret file “demosecret”
That is it.. now we are ready to launch the Pod and inject the secret as environment variable.
The following code sample will demonstrate how the pod will read the secrets as environment variable.
Java Demo
Rest API service that shows the value of the secret passed to pod as environment variable. The main class shows how we retrieve the secrets using annotation @Value
You will notice POM file does not have KeyVault library dependency in this demo.
Pipeline Review
The pipeline “azure-pipelines-java-csi.yml” has 3 stages as shows in the following figure
- Java Build: using Maven will package the app and publish it with chart
- Docker Build: using docker will build an image and publish it to ACR
- Helm Deployment: using helm will connect to AKS then install helm chart under namespace “demo”. Please notice how we are passing new chart values as arguments
Once it runs, we should see the following:
C# Demo
Source Code Review
Demo is identical to Java code. Rest API service that shows secret passed to pod as env variable.
The pipeline for ““azure-pipelines-csharp-csi.yml” is follow same structure of 3 stages
- CSharp Build: using dotnet will package the app and publish it with chart
- Docker Build: using docker will build an image and publish it to ACR
- Helm Deployment: using helm will connect to AKS then install helm chart under namespace “demo”. Please notice how we are passing new chart values as arguments
Python Demo
Source Code Review
Python code is a FlaskRest API example.
The pipeline for ““azure-pipelines-python-csi.yml” is follow same structure of 2 stages.
- Docker Build: using docker will build an image and publish it to ACR
- Helm Deployment: using helm will connect to AKS then install helm chart under namespace “demo”. Please notice how we are passing new chart values as arguments.
Check our work:
Once we get pipelines deployed for all application, we can review the deployed resources.
- Check Charts
- Check Pods
- Check Services
- Check Ingress
- Use Postman to call apps using ingress host.
Java demo endpoint
Python demo
C# demo
Summary
Today we concluded this series by we discussed how to use Secret Store CSI Driver. In this series we discussed how to use Terraform and Azure Pipeline to deploy AKS fully integrated with AD, we also show how to deploy add-ons for Pod Identity and csi-driver objects. Then we discussed how to use Pod Identity with your application and finally we closed the series by showing how to leaverage Secret Store CSI Driver with Pod Identity to present the pods with the secrets.
Thank you for Reading!