Login via Device Impossible due to Timezone Mismatch

[georglauterbach]

I'm running BW 2024.8.1-beta in a Kubernetes cluster with k8tz. k8tz properly sets /etc/localtime inside my pods. The BW pod has the correct timezone set: CEST (UTC+2).

My client, the iOS App, receives login requests from the self-hosted server, which is running quite well. The request can never be fulfilled, though, because the request is shown as "2 hours ago", i.e. the request has become invalid. Is there something I am missing, something like "we always use UTC everywhere"? I tested without k8tz before, and had the same issue (i.e. the contents of /etc/localtime do not seem to matter).

Any help is appreciated :)

CC @vgrassia

[keithhubner]

Hi, can you share your deployment manifest so I can try and reproduce this? Thanks!

[georglauterbach]

Deployment

```yaml --- apiVersion: apps/v1 kind: Deployment metadata: name: bitwarden annotations: ignore-check.kube-linter.io/run-as-non-root: >- Bitwarden needs to run as root ignore-check.kube-linter.io/no-read-only-root-fs: >- There are too many files written to make the root FS read-only spec: replicas: 1 selector: matchLabels: app: bitwarden template: metadata: labels: app: bitwarden app.traefik.io/communication: 'true' spec: terminationGracePeriodSeconds: 120 restartPolicy: Always dnsConfig: options: - name: ndots value: '1' - name: trust-ad - name: edns0 volumes: - name: vol-data persistentVolumeClaim: claimName: bitwarden-data - name: vol-tmp emptyDir: {} hostname: bitwarden containers: # ref: https://bitwarden.com/de-DE/help/install-and-deploy-unified-beta/ # https://github.com/bitwarden/self-host - name: bitwarden # The [Unified Deployment Open # Beta](https://bitwarden.com/blog/new-deployment-option-for-self-hosting-bitwarden/) # is used here. image: docker.io/bitwarden/self-host:2024.8.2-beta imagePullPolicy: IfNotPresent securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: false runAsUser: 0 runAsGroup: 0 runAsNonRoot: false privileged: false appArmorProfile: type: RuntimeDefault capabilities: add: # file permission capabilities - CHOWN - FOWNER - MKNOD - SETGID - SETUID - DAC_OVERRIDE # miscellaneous capabilities - SYS_CHROOT - SYS_PTRACE - KILL drop: [ ALL ] seccompProfile: type: RuntimeDefault resources: limits: memory: 1500Mi cpu: '1' requests: memory: 650Mi cpu: 100m volumeMounts: - name: vol-data mountPath: /etc/bitwarden readOnly: false - name: vol-tmp mountPath: /tmp readOnly: false ports: - name: web-interface containerPort: 8080 protocol: TCP envFrom: # The correct [environment # variables](https://bitwarden.com/help/install-and-deploy-unified-beta/#environment-variables) # have to be set, e.g., the correct [location](https://bitwarden.com/help/server-geographies/). - configMapRef: name: bitwarden-environment - secretRef: name: bitwarden-environment - secretRef: name: database-environment startupProbe: httpGet: path: /api/alive port: web-interface periodSeconds: 30 failureThreshold: 5 timeoutSeconds: 5 livenessProbe: httpGet: path: /api/alive port: web-interface periodSeconds: 300 failureThreshold: 2 timeoutSeconds: 5 ```

k8tz uses an additional initContainer

  initContainers:
    - name: k8tz
      image: quay.io/k8tz/k8tz:0.16.2
      args:
        - bootstrap
      resources: {}
      volumeMounts:
        - name: k8tz
          mountPath: /mnt/zoneinfo
        - name: kube-api-access-26q5k
          readOnly: true
          mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: File
      imagePullPolicy: IfNotPresent
      securityContext:
        capabilities:
          drop:
            - ALL
        allowPrivilegeEscalation: false
        seccompProfile:
          type: RuntimeDefault

to make /etc/localtime point to CEST+2 (Europe/Berlin). It also sets an ENV variable for BitWarden:

      env:
        - name: TZ
          value: Europe/Berlin

[georglauterbach]

I have now also observed this in a mail BW sent to me about a new login. Hence, it is very likely connected to https://github.com/bitwarden/server/issues/494. This also seems to be an issue that exists for a long time now; is the fix non-trivial? Using local time for e-mails and push notifications should not be too hard, should it?

[georglauterbach]

Any update on this one? It seems that, as soon as this topic is brought forward, silence takes over and no one bothers. Is it really that hard? If I knew the project and had some time, I'd try myself. The non-self-hosted servers of BitWarden seem to get this straight, maybe it is even a misconfiguration on my side. But can we please do something about it?

[georglauterbach]

@keithhubner is there anything being done about this issue?

[KramNamez]

This also seems to affect Trusted Device Encryption - at least that also fails on my self-host, for unclear reasons, while I am also affected by this timezone issue.

[KramNamez]

We investigated and Bitwarden does, in fact, use UTC everywhere. That's hardcoded in the source and it does not respect any TZs you set.

What helped us (although it didn't fix everything; I'm still in touch with BW support) was to set the timezone of our DB to UTC explicitly. It had been set to localtime, which caused a mismatch. This is not the timezone in the pods, which isn't relevant, this is specifically in the DB. We built an initContainer that connects to the DB and sets the timezone.

(Yes, technically it only needs to be done once, but this way, we can recreate everything from scratch and it'll include that too.)

Hope that helps you too!

[georglauterbach]

You, sir, are the Bitwarden-Timezone-GOAT! This solved it for me as well! Thank you so much for sharing your insight in this thread! I hope that other, who stumble upon this issue, may also benefit from your answer.

Here are the commands I used to change the time zone for PostgreSQL:

$ psql <BW DATABASE NAME> bitwarden
ALTER DATABASE <BW DATABASE NAME> SET timezone TO 'UTC';
set timezone TO 'GMT';
SET TIME ZONE 'UTC';
\q

Then I restarted Bitwarden and PostgreSQL.

[KramNamez]

Thanks goes to my colleague, who overhears me wondering about the timezone and goes "did you check what the DB is set to? It might not be down to what's in the pods..."

That was the clue that solved it. Thanks for posting the command, that should be helpful to others, too. It really only needs one: ALTER DATABASE <name> SET TIME ZONE 'UTC';