[GH-ISSUE #1174] bitwarden restarting changes duo back to enable: false #828

Closed
opened 2026-03-03 02:03:40 +03:00 by kerem · 7 comments
Owner

Originally created by @shanehughes1990 on GitHub (Oct 6, 2020).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/1174

Good afternoon, Not sure this is a bug maybe just a missed config on my part, We have duo setup works flawlessly the whole bitwardenrs installation has gone by flawlessly, My only issue is whenever the docker container restarts the Duo settings in /admin get reset to enabled: false (the ikey skey and host all persist). I suppose the question is, is there a DUO_ENABLED environment variable I need to use to persist that setting? I did not see one in https://github.com/dani-garcia/bitwarden_rs/blob/master/.env.template
I also noticed there is no config.json in /data inside the container once running. I'm pretty sure that's because its the mysql variant, correct me if I am wrong?

If you are unfamiliar with kubernetes you can basically ignore everything in the following deployment file except for the container {} chunk.

Your environment

We are running kubernetes 1.18.X in gcp.
Bitwarden rs is bitwardenrs/server-mysql:1.16.3
Deployed using terraform

The following the the terraform deployment file

resource "kubernetes_deployment" "app" {
  metadata {
    name = var.name
    namespace = var.namespace
    labels = {
      app = var.name
    }
  }

  spec {
    replicas = var.replicas
    progress_deadline_seconds = var.progress_deadline_seconds

    strategy {
      type = var.update_strategy
      }

    selector {
      match_labels = {
        app = var.name
      }
    }

    template {
      metadata {
        labels = {
          app = var.name
        }
      }

      spec {
        affinity {
          node_affinity {
            required_during_scheduling_ignored_during_execution {
              node_selector_term {
                match_expressions {
                  key      = var.node_affinity_key
                  operator = "In"
                  values = [
                    var.node_affinity_value
                  ]
                }
              }
            }
          }
        }

        container {
          image = "${var.image_url}:${var.image_tag}"
          name  = var.name

          port {
            name = "app-port"
            container_port = "80"
          }

          env {
            name = "DOMAIN"
            value = "https://${var.domain_name}"
          }

          env {
            name = "SIGNUPS_ALLOWED"
            value = var.signups_allowed
          }

          env {
            name = "INVITATIONS_ALLOWED"
            value = var.invitations_allowed
          }

          # Example: mysql://dbuser:yourpassword@192.168.1.10:3306/bitwarden
          env {
            name = "DATABASE_URL"
            value_from {
              secret_key_ref {
                name = kubernetes_secret.app.metadata[0].name
                key = "mysql_connection_string"
              }
            }
          }

          env {
            name = "ADMIN_TOKEN"
            value_from {
              secret_key_ref {
                name = kubernetes_secret.app.metadata[0].name
                key = "admin_token"
              }
            }
          }

          # Disabling WAL was recommended due to having external SQL database
          # https://github.com/dani-garcia/bitwarden_rs/wiki/Running-without-WAL-enabled
          env {
            name = "ENABLE_DB_WAL"
            value = "false"
          }

          env {
            name = "SMTP_HOST"
            value = var.smtp_host
          }

          env {
            name = "SMTP_FROM"
            value = var.smtp_from
          }

          env {
            name = "SMTP_PORT"
            value = var.smtp_port
          }

          env {
            name = "SMTP_USERNAME"
            value = var.smtp_username
          }

          env {
            name = "SMTP_FROM_NAME"
            value = "Bitwarden"
          }

          env {
            name = "SMTP_PASSWORD"
            value_from {
              secret_key_ref {
                name = kubernetes_secret.app.metadata[0].name
                key = "smtp_password"
              }
            }
          }

          env {
            name = "DUO_IKEY"
            value_from {
              secret_key_ref {
                name = kubernetes_secret.app.metadata[0].name
                key = "duo_ikey"
              }
            }
          }

          env {
            name = "DUO_SKEY"
            value_from {
              secret_key_ref {
                name = kubernetes_secret.app.metadata[0].name
                key = "duo_skey"
              }
            }
          }

          env {
            name = "DUO_HOST"
            value_from {
              secret_key_ref {
                name = kubernetes_secret.app.metadata[0].name
                key = "duo_host"
              }
            }
          }

          resources {
            limits {
              cpu    = var.cpu_limit
              memory = var.memory_limit
            }
            requests {
              cpu    = var.cpu_request
              memory = var.memory_request
            }
          }

          liveness_probe {
            http_get {
              path = "/"
              port = 80
            }

            initial_delay_seconds = 15
            period_seconds        = 15
            timeout_seconds       = 15
            failure_threshold     = 10
            success_threshold     = 1
          }

          readiness_probe {
            http_get {
              path = "/"
              port = 80
            }

            initial_delay_seconds = 15
            period_seconds        = 15
            timeout_seconds       = 10
            failure_threshold     = 10
            success_threshold     = 1
          }
        }
      }
    }
  }
}

Steps to reproduce

Suppose the easiest way would be to deploy via docker compose and add the mysql & duo environment variables

Expected behaviour

Duo enabled: true

Actual behaviour

Upon start/restart Duo setting in /admin changes from enabled: true to enabled: false

Relevant logs

image

Originally created by @shanehughes1990 on GitHub (Oct 6, 2020). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/1174 Good afternoon, Not sure this is a bug maybe just a missed config on my part, We have duo setup works flawlessly the whole bitwardenrs installation has gone by flawlessly, My only issue is whenever the docker container restarts the Duo settings in /admin get reset to enabled: false (the ikey skey and host all persist). I suppose the question is, is there a DUO_ENABLED environment variable I need to use to persist that setting? I did not see one in https://github.com/dani-garcia/bitwarden_rs/blob/master/.env.template I also noticed there is no config.json in /data inside the container once running. I'm pretty sure that's because its the mysql variant, correct me if I am wrong? If you are unfamiliar with kubernetes you can basically ignore everything in the following deployment file except for the container {} chunk. #### Your environment We are running kubernetes 1.18.X in gcp. Bitwarden rs is bitwardenrs/server-mysql:1.16.3 Deployed using terraform The following the the terraform deployment file ``` resource "kubernetes_deployment" "app" { metadata { name = var.name namespace = var.namespace labels = { app = var.name } } spec { replicas = var.replicas progress_deadline_seconds = var.progress_deadline_seconds strategy { type = var.update_strategy } selector { match_labels = { app = var.name } } template { metadata { labels = { app = var.name } } spec { affinity { node_affinity { required_during_scheduling_ignored_during_execution { node_selector_term { match_expressions { key = var.node_affinity_key operator = "In" values = [ var.node_affinity_value ] } } } } } container { image = "${var.image_url}:${var.image_tag}" name = var.name port { name = "app-port" container_port = "80" } env { name = "DOMAIN" value = "https://${var.domain_name}" } env { name = "SIGNUPS_ALLOWED" value = var.signups_allowed } env { name = "INVITATIONS_ALLOWED" value = var.invitations_allowed } # Example: mysql://dbuser:yourpassword@192.168.1.10:3306/bitwarden env { name = "DATABASE_URL" value_from { secret_key_ref { name = kubernetes_secret.app.metadata[0].name key = "mysql_connection_string" } } } env { name = "ADMIN_TOKEN" value_from { secret_key_ref { name = kubernetes_secret.app.metadata[0].name key = "admin_token" } } } # Disabling WAL was recommended due to having external SQL database # https://github.com/dani-garcia/bitwarden_rs/wiki/Running-without-WAL-enabled env { name = "ENABLE_DB_WAL" value = "false" } env { name = "SMTP_HOST" value = var.smtp_host } env { name = "SMTP_FROM" value = var.smtp_from } env { name = "SMTP_PORT" value = var.smtp_port } env { name = "SMTP_USERNAME" value = var.smtp_username } env { name = "SMTP_FROM_NAME" value = "Bitwarden" } env { name = "SMTP_PASSWORD" value_from { secret_key_ref { name = kubernetes_secret.app.metadata[0].name key = "smtp_password" } } } env { name = "DUO_IKEY" value_from { secret_key_ref { name = kubernetes_secret.app.metadata[0].name key = "duo_ikey" } } } env { name = "DUO_SKEY" value_from { secret_key_ref { name = kubernetes_secret.app.metadata[0].name key = "duo_skey" } } } env { name = "DUO_HOST" value_from { secret_key_ref { name = kubernetes_secret.app.metadata[0].name key = "duo_host" } } } resources { limits { cpu = var.cpu_limit memory = var.memory_limit } requests { cpu = var.cpu_request memory = var.memory_request } } liveness_probe { http_get { path = "/" port = 80 } initial_delay_seconds = 15 period_seconds = 15 timeout_seconds = 15 failure_threshold = 10 success_threshold = 1 } readiness_probe { http_get { path = "/" port = 80 } initial_delay_seconds = 15 period_seconds = 15 timeout_seconds = 10 failure_threshold = 10 success_threshold = 1 } } } } } } ``` ### Steps to reproduce Suppose the easiest way would be to deploy via docker compose and add the mysql & duo environment variables ### Expected behaviour Duo enabled: true ### Actual behaviour Upon start/restart Duo setting in /admin changes from enabled: true to enabled: false ### Relevant logs ![image](https://user-images.githubusercontent.com/31993465/95245365-0651eb00-07e1-11eb-9e2c-2550e9e8e1f1.png)
kerem closed this issue 2026-03-03 02:03:41 +03:00
Author
Owner

@shanehughes1990 commented on GitHub (Oct 6, 2020):

Sorry quick update was just doing some testing, it appears the config.json file gets created only IF I change something in /admin, So I can import a config.json I think to get around my issue would be better if there was just an environment variable to enable it though

<!-- gh-comment-id:704482224 --> @shanehughes1990 commented on GitHub (Oct 6, 2020): Sorry quick update was just doing some testing, it appears the config.json file gets created only IF I change something in /admin, So I can import a config.json I think to get around my issue would be better if there was just an environment variable to enable it though
Author
Owner

@jjlin commented on GitHub (Oct 6, 2020):

If you hover over the config item, you can see the item name (_enable_duo in this case), then uppercase it for the env var name: _ENABLE_DUO

<!-- gh-comment-id:704495546 --> @jjlin commented on GitHub (Oct 6, 2020): If you hover over the config item, you can see the item name (`_enable_duo` in this case), then uppercase it for the env var name: `_ENABLE_DUO`
Author
Owner

@shanehughes1990 commented on GitHub (Oct 6, 2020):

Oh that's wonderful thank you very much, This I presume is this way for ANY env listed in config.json?

<!-- gh-comment-id:704496520 --> @shanehughes1990 commented on GitHub (Oct 6, 2020): Oh that's wonderful thank you very much, This I presume is this way for ANY env listed in config.json?
Author
Owner

@BlackDex commented on GitHub (Oct 6, 2020):

If this is a user toggle, then i think we actually need to remove the _ in my opinion. Since all _ vars should not changeable via env i think

<!-- gh-comment-id:704497222 --> @BlackDex commented on GitHub (Oct 6, 2020): If this is a user toggle, then i think we actually need to remove the _ in my opinion. Since all _ vars should not changeable via env i think
Author
Owner

@shanehughes1990 commented on GitHub (Oct 6, 2020):

Why not? this would mean I would need a config.json to enable duo on start would it not?

<!-- gh-comment-id:704497623 --> @shanehughes1990 commented on GitHub (Oct 6, 2020): Why not? this would mean I would need a config.json to enable duo on start would it not?
Author
Owner

@BlackDex commented on GitHub (Oct 6, 2020):

No, it means the exact opposite. In my opinion vars starting with an _ should not be user editable. So i think we need to change that var to not have an _.

The reason is, there are a few of those _ vars which could cause issues if users can change them i think.

<!-- gh-comment-id:704503703 --> @BlackDex commented on GitHub (Oct 6, 2020): No, it means the exact opposite. In my opinion vars starting with an _ should not be user editable. So i think we need to change that var to not have an _. The reason is, there are a few of those _ vars which could cause issues if users can change them i think.
Author
Owner

@shanehughes1990 commented on GitHub (Oct 6, 2020):

Yeah I read it again and realized what it was you were saying :P, FWY fix worked flawlessly its officially ready for me to move release it to our employees :) so thanks for everyone's help

<!-- gh-comment-id:704527967 --> @shanehughes1990 commented on GitHub (Oct 6, 2020): Yeah I read it again and realized what it was you were saying :P, FWY fix worked flawlessly its officially ready for me to move release it to our employees :) so thanks for everyone's help
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/vaultwarden#828
No description provided.