Autoaloja con Helm

Este artículo le guiará a través del procedimiento para instalar y desplegar Bitwarden en diferentes despliegues de Kubernetes utilizando un gráfico de Helm.

Este artículo describirá los pasos genéricos para alojar Bitwarden en Kubernetes. Guías específicas del proveedor están disponibles para profundizar en cómo podrías alterar una implementación basada en las ofertas específicas de cada proveedor:

• Despliegue de Azure AKS

• Despliegue de OpenShift

• Despliegue de AWS EKS

Antes de proceder con la instalación, asegúrese de que se cumplan los siguientes requisitos:

• kubectl está instalado.

• Helm 3 está instalado.

• Tienes un certificado SSL y una clave o acceso para crear uno a través de un proveedor de certificados.

• Tienes un servidor SMTP o acceso a un proveedor de SMTP en la nube.

• Una clase de almacenamiento que admite ReadWriteMany.

• Tienes una identificación de instalación y una clave obtenida de https://bitwarden.com/host.

Agrega el repositorio a Helm usando los siguientes comandos:

BashCopy
helm repo add bitwarden https://charts.bitwarden.com/
helm repo update

Crea un espacio de nombres para desplegar Bitwarden. Nuestra documentación asume un espacio de nombres llamado Bitwarden, así que asegúrate de modificar los comandos si eliges un nombre diferente.

BashCopy
kubectl create namespace bitwarden

Crea un archivo de configuración my-values.yaml, que utilizarás para personalizar tu implementación, utilizando el siguiente comando:

BashCopy
helm show values bitwarden/self-host > my-values.yaml

Como mínimo, debes configurar los siguientes valores en tu archivo my-values.yaml:

Crea un objeto secreto de Kubernetes para establecer, como mínimo, los siguientes valores:

Por ejemplo, usar el comando kubectl create secret para establecer estos valores se vería de la siguiente manera:

BashCopy
kubectl create secret generic custom-secret -n bitwarden \
    --from-literal=globalSettings__installation__id="REPLACE" \
    --from-literal=globalSettings__installation__key="REPLACE" \
    --from-literal=globalSettings__mail__smtp__username="REPLACE" \
    --from-literal=globalSettings__mail__smtp__password="REPLACE" \
    --from-literal=globalSettings__yubico__clientId="REPLACE" \
    --from-literal=globalSettings__yubico__key="REPLACE" \
    --from-literal=globalSettings__hibpApiKey="REPLACE" \
    --from-literal=SA_PASSWORD="REPLACE"

No olvides establecer el valor de secrets.secretName: en my-values.yaml al nombre del secreto creado, en este caso custom-secret.

El despliegue requiere un certificado y clave TLS, o acceso a la creación de uno a través de un proveedor de certificados. El siguiente ejemplo te guiará a través del uso de cert-manager para generar un certificado con Let's Encrypt:

1. Instale cert-manager en el clúster utilizando el siguiente comando:

   BashCopy
   kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.yaml

2. Definir un emisor de certificados. Bitwarden recomienda usar la configuración de Staging en este ejemplo hasta que tus registros DNS hayan sido apuntados a tu clúster. Asegúrate de reemplazar el marcador de posición correo electrónico: con un valor válido:

   • Escenificación
   • Producción

   BashCopy
   cat <<EOF | kubectl apply -n bitwarden -f -
   apiVersion: cert-manager.io/v1
   kind: ClusterIssuer
   metadata:
     name: letsencrypt-staging
   spec:
     acme:
       server: https://acme-staging-v02.api.letsencrypt.org/directory
       email: me@example.com
       privateKeySecretRef:
         name: tls-secret
       solvers:
         - http01:
             ingress:
               class: nginx #use "azure/application-gateway" for Application Gateway ingress
   EOF

   BashCopy
   cat <<EOF | kubectl apply -n bitwarden -f -
   apiVersion: cert-manager.io/v1
   kind: ClusterIssuer
   metadata:
     name: letsencrypt-production
   spec:
     acme:
       server: https://acme-v02.api.letsencrypt.org/directory
       email: me@example.com
       privateKeySecretRef:
         name: tls-secret
       solvers:
         - http01:
             ingress:
               class: nginx #use "azure/application-gateway" for Application Gateway ingress
   EOF

3. Si aún no lo has hecho, asegúrate de establecer los valores general.ingress.cert.tls.name: y general.ingress.cert.tls.clusterIssuer: en my-values.yaml. En este ejemplo, ajustarías:

   • general.ingress.cert.tls.name: tls-secret

   • general.ingress.cert.tls.clusterIssuer: letsencrypt-staging

El gráfico de Helm autoalojado de Bitwarden te permite incluir otros archivos de manifiesto de Kubernetes ya sea antes o después de la instalación. Para hacer esto, actualiza la sección rawManifests del gráfico (aprende más). Esto es útil, por ejemplo, en escenarios donde quieres usar un controlador de ingreso distinto al controlador nginx definido por defecto.

Para instalar Bitwarden con la configuración establecida en my-values.yaml, ejecute el siguiente comando:

BashCopy
helm upgrade bitwarden bitwarden/self-host --install --namespace bitwarden --values my-values.yaml

¡Felicidades! Bitwarden ahora está en funcionamiento en https://your.domain.com, según se define en my-values.yaml. Visita la caja fuerte web en tu navegador web para confirmar que está funcionando. Ahora puedes registrar una nueva cuenta e iniciar sesión.

Necesitará haber configurado una configuración SMTP y secretos relacionados para verificar el correo electrónico de su nueva cuenta.

En este repositorio, hemos proporcionado dos trabajos de ejemplo ilustrativos para hacer copias de seguridad y restaurar la base de datos en el pod de la base de datos de Bitwarden. Si está utilizando su propia instancia de SQL Server que no se implementó como parte de este gráfico de Helm, siga las políticas de respaldo y restauración de su empresa.

Las copias de seguridad de la base de datos y las políticas de copia de seguridad dependen en última instancia del implementador. La copia de seguridad podría programarse fuera del clúster para ejecutarse a intervalos regulares, o podría modificarse para crear un objeto CronJob dentro de Kubernetes con fines de programación.

El trabajo de respaldo creará versiones con marca de tiempo de los respaldos anteriores. La copia de seguridad actual simplemente se llama vault.bak. Estos archivos se colocan en el volumen persistente de copias de seguridad de MS SQL. El trabajo de restauración buscará vault.bak en el mismo volumen persistente.