[abhichandra-v]

What

Non-breaking hardening + reliability for the Vaultwarden deployment:

• Pin the image to a specific release instead of :latest (shown as
  vaultwarden/server:1.32.7 — set it to whichever release you run), so a pod
  restart can't silently change versions.
• Add resource requests/limits (CPU, memory, ephemeral-storage) — the pod
  currently has none.
• Add liveness and readiness probes (liveness: TCP :80; readiness: HTTP
  /alive on :80, Vaultwarden's documented unauthenticated health endpoint).
• Add a container securityContext: allowPrivilegeEscalation: false,
  all capabilities dropped with only NET_BIND_SERVICE added back (Vaultwarden
  binds :80), and seccomp RuntimeDefault.

Why

This stores credentials, so defense-in-depth matters: no privilege escalation
and a near-empty capability set cost nothing here. Probes let Kubernetes
restart a hung pod and hold traffic until the app is serving, and pinning the
image removes the "what version is actually running" ambiguity.

Scope

Deliberately minimal and non-breaking. The Service, data volume, and port are
unchanged, and NET_BIND_SERVICE is kept so the container can still bind :80.
I left readOnlyRootFilesystem, a non-root UID, and a NetworkPolicy out — those
depend on the image and your cluster's networking and are better as separate
changes. The image is pinned, so imagePullPolicy is IfNotPresent rather
than Always. Verified the manifest still parses.

[cyberops7]

Appreciate the hardening here. I tested the securityContext and limits against the image, and Vaultwarden runs without trouble under them. /alive is a good choice for the readiness probe.

I'd like to drop the version pin, though, and keep :latest with imagePullPolicy: Always. Nothing in this repo bumps pinned tags, and people tend to copy these manifests once and leave them alone. A pin that's current today becomes an outdated password manager a year from now, and nothing tells the user. 1.32.7 already shows this: it's from December 2024 and misses fixes such as GHSA-j4h8-vch3-f797 (1.33.0) and the CVE fixes in 1.33.2 and 1.34.0. Vaultwarden has no major-version tags and migrates its database forward on its own, so following latest is the safer default for this app. A comment suggesting that readers pin a release and update it deliberately, if they want reproducible deploys, would be a welcome addition.

With the image line back to latest and Always, this is good to go.