guerzon/vaultwarden

Helm chart for Vaultwarden, the (unofficial) Bitwarden-compatible server written in Rust, formerly known as bitwarden_rs

Helm chart for Vaultwarden

Vaultwarden, formerly known as Bitwarden_RS, is an "alternative implementation of the Bitwarden server API written in Rust and compatible with upstream Bitwarden clients, perfect for self-hosted deployment where running the official resource-heavy service might not be ideal."

Description

This Helm chart is used to deploy vaultwarden with a stable configuration to Kubernetes clusters.

The vaultwarden project can be found here. To learn more about Vaultwarden, please visit the wiki.

Change of Resource Type in Versions >= 0.18.0

Starting from version 0.18.0, when a stateless configuration is detected that utilizes an external database and persistent storage, a Deployment is automatically used in favor of the current StatefulSet. This enables running multiple pods simultaneously, thereby enhancing the processes of updates, rollbacks, and scalability for load balancing. This automatic detection can be overridden by manually specifying a resourceType.

Prerequisites

• Kubernetes >= 1.12
• Helm >= 3.1.0
• docker and make for generating the chart documentation

Usage

Add the repository:

helm repo add vaultwarden https://guerzon.github.io/vaultwarden

Refer to the detailed documentation here.

Disclaimer

Please do your due-diligence before using this chart for a production deployment.

Nevertheless, if you find any issues while using this chart, or have any suggestions, I would appreciate it if you would submit an issue. Alternatively, PRs are appreciated!

License

See LICENSE.

Author

This Helm chart was created and maintained by Lester Guerzon.

Credits

• The vaultwarden project can be found here
• Further information about Bitwarden and 8bit Solutions LLC can be found here

References

• Guides: https://github.com/dani-garcia/vaultwarden/wiki
• Configuration: https://github.com/dani-garcia/vaultwarden/blob/main/.env.template
• Releases: https://github.com/dani-garcia/vaultwarden/releases

vaultwarden's Issues

helm chart `index.yaml` not found, so you can't install without cloning the repo

Thanks for maintaining this helm chart! It's super useful!

Currently getting:

helm repo add vaultwarden https://guerzon.github.io/vaultwarden
Error: 
looks like "https://guerzon.github.io/vaultwarden" is not a valid chart repository or cannot be reached: 
failed to fetch https://guerzon.github.io/vaultwarden/index.yaml :
404 Not Found

I am using the same releaser as you are, and I think it's not working because you need to enable write permissions for the github action workflow. You can set those in the workflow file itself using these docs.

The easiest way though, is to select "Read and Write Permissions" under Settings > Actions > General > Workflow permissions:

You can check if it's working by checking the gh-pages branch for a repo root level "index.yaml", which should look something like this.

This would make it so no one has to clone your repo to install the chart.

infinite reset of sessions if more than one replica

infinite reset of sessions if more then one replica when you try to login more then 1 or 2 times

Feature request: add other variables to configmap

First of all thank you for this chart and keeping it up to date.

There are some other variables that can be added to the configmap to support extra features:

• ORG_CREATION_USERS: list of users that can create and manage organizations;
• SENDS_ALLOWED: enable/disable the use of sends;
• EMERGENCY_ACCESS_ALLOWED: if it is possible to enable emergency access;
• TZ: the timezone, if we need it to be different than the one in the host

To get a full list, you can check how Gissi does it on his chart (that is abandoned apparently) at https://github.com/gissilabs/charts/tree/master/vaultwarden

Recent change to recommended labels breaks upgrading since you cannot modify labels of StatefulSet

This breaks upgrading since you cannot modify labels of StatefulSet

Originally posted by @dolohow in #22 (comment)

Question: Should we use "default" storageclass name as default?

The template of pvc has a default value called "default" on storageClassName.

vaultwarden/charts/vaultwarden/templates/statefulset.yaml

Line 132 in 95de29e

storageClassName: {{ default "default" .Values.storage.class }}

Isn't that will make pvc asking for a storage class named default instead of asking for a default storage class?

Question: Use a Deployment when using external database?

Does it make sense to use a Deployment instead of a StatefulSet when using an external database like PostgreSQL?

When using an external database there is no need for the vaultwarden-data volume correct?

Helm recommended labels

Hey, i noticed that u removed the standard templates used by helm, usually defined at _helpers.tpl file. Is there any reason for it?
This way helm won't be able to track its own manifests within k8s cluster.
You should at least include the recommended labels into the generated helm manifests, such as app.kubernetes.io/name. helm.sh/chart, app.kubernetes.io/managed-by and app.kubernetes.io/instance

{{/*
Common labels
*/}}
{{- define "test.labels" -}}
helm.sh/chart: {{ include "test.chart" . }}
{{ include "test.selectorLabels" . }}
{{- if .Chart.AppVersion }}
app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}
{{- end }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end }}

{{/*
Selector labels
*/}}
{{- define "test.selectorLabels" -}}
app.kubernetes.io/name: {{ include "test.name" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
{{- end }}

Just a suggestion.

Feature: Make the chart available with a chart repository

It would be useful to add an index.yaml to this repo, so tools like Kustomize could make use of this chart.

A GitHub Action like Chart Releaser Action would automate this easily.

Websocket notification path/ingress

Hey, i noticed that you are using ImplementationSpecific as default pathTypeWs at WS ingress part.
As shown here:

  path: "/"
  ## @param ingress.pathWs Path for the websocket ingress
  ##
  pathWs: "/notifications/hub"
  ## @param ingress.pathType Path type for the ingress
  ## Ref: https://kubernetes.io/docs/concepts/services-networking/ingress/
  ##
  pathType: "ImplementationSpecific"
  ## @param ingress.pathTypeWs Path type for the ingress
  ## Ref: https://kubernetes.io/docs/concepts/services-networking/ingress/
  ##
  pathTypeWs: "ImplementationSpecific"

And this is how you set the ingress template:

  rules:
    - host: {{ .Values.ingress.hostname | quote }}
      http:
        paths:
        - path: {{ .Values.ingress.path }}
          pathType: {{ .Values.ingress.pathType }}
          backend:
            service:
              name: {{ include "vaultwarden.fullname" . }}
              port:
                name: "http"
        {{- if .Values.websocket.enabled }}
        - path: {{ .Values.ingress.pathWs }}
          pathType: {{ .Values.ingress.pathTypeWs }}
          backend:
            service:
              name: {{ include "vaultwarden.fullname" . }}
              port:
                name: "websocket"
        {{- end }}

But according to the official documentation:

To enable WebSockets notifications, an external reverse proxy is necessary, and it must be configured to do the following:
Route the /notifications/hub endpoint to the WebSocket server, by default at port 3012, making sure to pass the Connection and Upgrade headers. (Note the port can be changed with WEBSOCKET_PORT variable)
Route everything else, including /notifications/hub/negotiate, to the standard Rocket server, by default at port 80.

So, if i understand correctly, only /notifications/hub should reach to WS port. Thus, pathTypeWs should be Exact instead of ImplementationSpecific for nginx-ingress-controller, right?

Add ability to configure annotations on StatefulSet

Migrate vaultwarden docker compose to kubernetes

Hi team,

I actualy have an up to date vaultwarden installed with docker compose.

I have sevreal users, and a liscence for an organisation.

Is their any easy solution to migrate this installation to this helm chart version ?

Thank you for your help.

Latest update to chart V0.17.0 breaks upgrade process

When trying to upgrade an existing vaultwarden deployment based on chart version 0.16.1 to chart 0.17.0 the helm deployment fails with:

Error: UPGRADE FAILED: cannot patch "vault-vaultwarden" with kind StatefulSet: StatefulSet.apps "vault-vaultwarden" is invalid: spec: Forbidden: updates to statefulset spec for fields other than 'replicas', 'ordinals', 'template', 'updateStrategy', 'persistentVolumeClaimRetentionPolicy' and 'minReadySeconds' are forbidden

I guess this is related to changes made in the volumeMounts: section.

Feature: Add support for running multiple replicas

Requirements:

Proposal:

Some vars can't be set to allow Non-SSL auth mehanism for SMTP

According to this dani-garcia/vaultwarden#3477 I think it should be possibility to left this variables empty.

Possible solution:

in the configmap add:

  {{- if .Values.smtp.authMechanism }}
  SMTP_AUTH_MECHANISM: {{ .Values.smtp.authMechanism | quote }}
  {{- end }}

in the statefulset add:

 {{- if .Values.smtp.username }}
            - name: SMTP_USERNAME
              valueFrom:
                secretKeyRef:
                  name: {{ include "vaultwarden.fullname" . }}
                  key: SMTP_USERNAME
            {{- end }}
            {{- if .Values.smtp.password }}
            - name: SMTP_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: {{ include "vaultwarden.fullname" . }}
                  key: SMTP_PASSWORD
            {{- end }}

I can prepare a pull request with these changes.

Question: what is the purpose of rbac role in this chart?

Hello!

I tried to realise what is the purpose of rbac role in this chart? We need these permissions if Bitwarden pod needs to modify some Kubernetes resources, but I am unsure that Bitwarden pod does this. I didn't find any related information in README.md.

From my perspective these permissions listed in RBAC role are unnecessary.

rules:
  - apiGroups: ["extensions", "apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["create","delete","get","list","patch","update","watch"]
  - apiGroups: [""]
    resources: ["pods/exec"]
    verbs: ["create","delete","get","list","patch","update","watch"]
  - apiGroups: [""]
    resources: ["pods/log"]
    verbs: ["get","list","watch"]
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get"]

Could somebody clarify this?

Add https

Hello
do you think to add https on rocket service to manage end to end encryption ?