Pin openbao secrets plugins to exact versions #492

Merged
benvin merged 1 commits from benvin/pin-openbao-plugin-versions into develop 2026-07-20 23:46:37 +10:00
Owner

Why

ensure: present/latest lets the plugin binaries drift from the sha256 pinned in the terraform-vault catalog (config/plugins/*.yaml). On the next OpenBao restart, a drifted binary fails the sha check and the plugin won't launch — a latent footgun (hit exactly this with rancher on ensure: latest).

Changes

Pin each secrets plugin to the version whose binary matches its registered catalog sha (all verified against the RPMs in rpm-internal):

  • openbao-plugin-secrets-litellm: 0.1.1 (sha 2263ebcb…)
  • openbao-plugin-secrets-gpg: 0.1.0 (sha 0e92d740…)
  • openbao-plugin-secrets-rancher: 0.1.1 (sha 9e597cd9…; was ensure: latest)

All three are no-op on the binary (installed versions already match) — this just locks them so a future release can't silently upgrade the binary out of lockstep with the catalog.

openbao-plugins (base bundle) left unpinned — its version couldn't be verified from the tooling side and it tracks the openbao package, not a catalog sha.

Note

To upgrade a plugin in future: bump the RPM version here and the catalog sha256 in terraform-vault in the same change, then vault write sys/plugins/reload/backend plugin=<name>.

## Why `ensure: present`/`latest` lets the plugin binaries drift from the sha256 pinned in the terraform-vault catalog (`config/plugins/*.yaml`). On the next OpenBao restart, a drifted binary fails the sha check and the plugin won't launch — a latent footgun (hit exactly this with rancher on `ensure: latest`). ## Changes Pin each secrets plugin to the version whose binary matches its registered catalog sha (all verified against the RPMs in rpm-internal): - `openbao-plugin-secrets-litellm`: **0.1.1** (sha 2263ebcb…) - `openbao-plugin-secrets-gpg`: **0.1.0** (sha 0e92d740…) - `openbao-plugin-secrets-rancher`: **0.1.1** (sha 9e597cd9…; was `ensure: latest`) All three are no-op on the binary (installed versions already match) — this just locks them so a future release can't silently upgrade the binary out of lockstep with the catalog. `openbao-plugins` (base bundle) left unpinned — its version couldn't be verified from the tooling side and it tracks the openbao package, not a catalog sha. ## Note To upgrade a plugin in future: bump the RPM version here **and** the catalog sha256 in terraform-vault in the same change, then `vault write sys/plugins/reload/backend plugin=<name>`.
unkinben added 1 commit 2026-07-20 23:42:18 +10:00
ensure: present/latest let the plugin binaries drift from the sha256 pinned in
the terraform-vault catalog (config/plugins/*.yaml); on the next OpenBao restart
a drifted binary fails the sha check and the plugin won't launch. Pin each to
the version whose binary matches its registered sha (all verified against the
RPMs):

- openbao-plugin-secrets-litellm: 0.1.1 (sha 2263ebcb…)
- openbao-plugin-secrets-gpg:     0.1.0 (sha 0e92d740…)
- openbao-plugin-secrets-rancher: 0.1.1 (sha 9e597cd9…; was ensure: latest)

openbao-plugins (base bundle) left unpinned.
benvin merged commit a69318b62d into develop 2026-07-20 23:46:37 +10:00
benvin deleted branch benvin/pin-openbao-plugin-versions 2026-07-20 23:46:37 +10:00
Sign in to join this conversation.
No Reviewers
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: unkin/puppet-prod#492