Search
StarWind is a hyperconverged (HCI) vendor with focus on Enterprise ROBO, SMB & Edge

Get Azure Key vault values from AKS

  • January 19, 2022
  • 5 min read
Cloud and Virtualization Architect. Florent is specializing in public, hybrid, and private cloud technologies. He is a Microsoft MVP in Cloud and Datacenter Management and an MCSE in Private Cloud.
Cloud and Virtualization Architect. Florent is specializing in public, hybrid, and private cloud technologies. He is a Microsoft MVP in Cloud and Datacenter Management and an MCSE in Private Cloud.


One of the last great features that Microsoft released few weeks ago is the possibility to get secrets into an Azure key Vault, from AKS, by using the Secret Store CSI (Container Storage Interface) Driver.

We already saw how to deploy an AKS cluster in previous articles.

To start we will check if the Key vault provider is already installed or not:

Key vault provider

As you can see, the addon part is null. We will now start to deploy the provider to this existing cluster, by using Azure CLI:

Start to deploy the providerIf you have the error Invalid addon name, be sure that your azure cli version is at least in version 2.30.0. If not, do az upgrade to have the last version:

Invalid addon nameSome pods have been deployed into the AKS cluster, to be able to use the secret store CSI driver:

Use the secret store CSI driver

A new User-Assigned managed identity has been created:

User-Assigned managed identity has been created

We will now create a new managed identity, for our app, App01. This app will need the access to the secret in our key vault, starwind-secret. You need to assign this identity to your VMSS, to be able to use it:

Assign this identity to your VMSS

Assign this identity to your VMSS

We will now give access to this MI, to the right key vault. A get is sufficient. If you use Azure Role Based access control, it will be more fine grained accesses:

Access control

When it is done, we will create our secret store in our AKS environment, to be able to bind it after, into a pod. Here is the code to create it:

Apply now this template to AKS. The new provider is created:

The new provider is created

We will now create a new pod, and try to mount this secret into it. I used a template provided by Microsoft to test the mount:

Adapt values with yours, depending of the name that you gave for the secretProviderClass. Apply it:

SecretProviderClass

We can now see in the mounted folder, that we have a secret mounted, and if we cat it, we have the value of it:

SecretProviderClass

As you can see, it is a good way to give access to DEV to a value stored in a key vault (key, secret or certificate). The advantage here is that you can create a MI per app, per environment, and give accesses to a specific secret in a specific key vault. And all of this, without managing password and renewal of password.

Hey! Found Florent’s article helpful? Looking to deploy a new, easy-to-manage, and cost-effective hyperconverged infrastructure?
Alex Bykovskyi
Alex Bykovskyi StarWind Virtual HCI Appliance Product Manager
Well, we can help you with this one! Building a new hyperconverged environment is a breeze with StarWind Virtual HCI Appliance (VHCA). It’s a complete hyperconverged infrastructure solution that combines hypervisor (vSphere, Hyper-V, Proxmox, or our custom version of KVM), software-defined storage (StarWind VSAN), and streamlined management tools. Interested in diving deeper into VHCA’s capabilities and features? Book your StarWind Virtual HCI Appliance demo today!