Azure AKS Deployment
This article dives into how you might alter your Bitwarden self-hosted Helm Chart deployment based on the specific offerings of Azure and AKS.
An nginx ingress controller is defined by default in
my-values.yaml. If you use this option:
Uncomment the values in the
my-values.yamland customize them as needed.
Azure customers may, however, prefer to use an Azure Application Gateway as the ingress controller for their AKS cluster.
Before installing the chart
If you prefer this option, before installing the chart you must:
Update your my-values.yaml file, specifically
If you're going to use the provided Let's Encrypt example for your TLS certificate, update
spec.acme.solvers.ingress.class:in the script linked here to
In the Azure Portal, create an empty rewrite set for Application Gateway:
Navigate to the Load balancing > Application Gateway in the Azure Portal and select your Application Gateway.
Select the Rewrites blade.
Select the Rewrite set button.
Set the Name to the value specified for
my-values.yaml, in this example
Select Next and Create.
After installing the chart
After installing the chart, you will also be required to create rules for your rewrite set:
Re-open the empty rewrite set you created before installing the chart.
Select all routing paths that begin with
pr-bitwarden-self-host-ingress..., de-select any that do not begin with that prefix, and select Next.
Select the Add Rewrite rule button. You can give your rewrite rule any name and any sequence.
Add the following condition:
Type of variable to check: Server variable
Server variable: uri_path
Operator: equal (=)
Pattern to match:
Add the following action:
Rewrite type: URL
Action type: Set
Components: URL path
URL path value:
Re-evaluate path map: Unchecked
Deployment requires a shared storage class that you provide, which must support ReadWriteMany. The following example is a script you can run in the Azure Cloud Shell to create an Azure File Storage class that meets the requirement:
The following is an illustrative example, be sure to assign permissions according to your own security requirements.
You must set the
sharedStorageClassName value in
my-values.yaml to whatever name you give the class, in this example:
Deployment requires Kubernetes secrets objects to set sensitive values for your deployment. While the
kubectl create secret command can be used to set secrets, Azure customers may prefer to use Azure Key Vault and the Secrets Store CSI Driver for AKS:
These instructions assume you already an have Azure Key Vault setup. If not, create one now.
Add Secrets Store CSI Driver support to your cluster with the following command:Bash
The add-on creates a user-assigned managed identity you can use to authenticate to your key vault, however you have other options for identity access control. If you use the created user-assigned managed identity, you will need to explicitly assign Secret > Get access to it (learn how).
Create a SecretProviderClass, as in the following example. Note that this example contains
<REPLACE>placeholders that you must replace and differs depending on if you are using the included SQL pod or using your own SQL server:Bash
Use the following commands to set the required secrets values in Key Vault:
This example will record commands to your shell history. Other methods may be considered to securely set a secret.Bash
my-values.yamlfile, set the following values:
secrets.secretName: Set this value to the
secretNamedefined in your SecretProviderClass.
secrets.secretProviderClass: Set this value to the
metadata.namedefined in your SecretProviderClass.