Skip to content

Migrated from ADR-0032 on 2026-05-02 per ADR-0047. Source file retained with deprecation banner at docs/adr/0032-workstation-secret-zero.md.

DEV-0003 — Workstation Secret Zero: OS Keyring for Infisical Bootstrap Credential

Field Value
Status Proposed
Date 2026-04-19
Author Ben Peries
Sources ADR-0032

Context

The CanEast AI Node WSL workstation (alienware-wsl) uses a Machine Identity in Infisical (Universal Auth, client ID REDACTED) to fetch secrets at shell init. ~/.bash_profile calls infisical login --method=universal-auth with the client secret in plaintext to export CLOUDFLARE_API_TOKEN and INFISICAL_TOKEN into the shell environment.

This pattern was established during DEV-0002 (CanEast AI Node workstation-as-code). It works, but it has a known security gap documented on 2026-04-19.

The Secret Zero Problem

Every secrets vault creates a bootstrap problem: the workload needs an initial credential to authenticate to the vault itself. That credential has to live somewhere. This is industry-known as the "Secret Zero" problem.

In the current setup: 

~/.bash_profile
  --> infisical login --client-secret=REDACTED
  --> Infisical returns INFISICAL_TOKEN
  --> infisical secrets get CLOUDFLARE_API_TOKEN

The client secret is the Secret Zero. It lives in plaintext in ~/.bash_profile.

This was confirmed in a live session on 2026-04-19 when an expired user session caused ~/.bash_profile to hang for 44 seconds at every shell open. The fix was to switch from user session auth to Machine Identity auth (Universal Auth), which does not expire. However, the Secret Zero problem remains.

Why Azure Key Vault Does Not Solve This

Azure Key Vault (AKV) eliminates Secret Zero cleanly for workloads running inside Azure via Managed Identity — no credential is needed because the Azure platform attests the workload identity directly.

However, the CanEast AI Node is an on-premises workstation running WSL. Managed Identity is only available to Azure-hosted compute (VMs, App Service, Container Apps). An on-prem workstation authenticating to AKV still requires an Azure SP client secret or certificate stored locally. The Secret Zero problem is identical — just a different vault.

AKV remains relevant for Archon in the context of Azure-hosted Terraform workloads where Managed Identity is available. That is tracked separately as a future ADR.

Why Enterprise PAM Does Not Apply

Enterprise PAM solutions (CyberArk, BeyondTrust) solve Secret Zero through agent-based attestation tied to Active Directory or hardware identity. This requires enterprise AD infrastructure not present in the Archon homelab.

Current State (Accepted Risk)

The client secret lives in ~/.bash_profile as plaintext. Risk is accepted as low for a homelab workstation with full-disk encryption and no shared access. However it fails the DEV-0002 workstation-as-code portability requirement: the file cannot be committed to git without redacting the secret, and a fresh workstation setup requires manual retrieval of a new client secret from the Infisical UI.

Decision Drivers

  • Eliminate plaintext Secret Zero from ~/.bash_profile
  • Survive workstation rebuild without manual Infisical UI interaction
  • Not introduce a new external dependency for a single on-prem workstation
  • Align with DEV-0002 workstation-as-code principles
  • Industry standard pattern for developer workstation credential bootstrap

Options Considered

Store the Infisical client secret in the Linux Secret Service (GNOME Keyring or KWallet), accessed via secret-tool. The keyring is unlocked by the user login session and protected at rest by the OS.

~/.bash_profile calls secret-tool lookup instead of embedding the plaintext secret. On a fresh workstation, the bootstrap script (alienware-setup.sh) prompts once for the client secret and stores it in the keyring. It is never written to a file.

Pros: No plaintext on disk. Survives reboots. Protected by login session. No new external dependency. Industry standard for developer workstations.

Cons: Requires GNOME Keyring or compatible Secret Service running in WSL. WSL does not run a full desktop session by default — keyring daemon must be started explicitly or via systemd user service. Adds WSL complexity.

Option 2: Encrypted file via GPG

Encrypt the client secret with the user GPG key. ~/.bash_profile calls gpg --decrypt at shell init. GPG key protected by passphrase cached in gpg-agent.

Pros: No external daemon dependency. GPG tooling already common on Linux. Cons: Requires gpg-agent passphrase entry after reboot. Not meaningfully better than the keyring approach.

Option 3: Azure Key Vault with certificate auth

Store the client secret in AKV. Authenticate to AKV using a local certificate.

Pros: Leverages existing AKV free tier. Certificate auth stronger than shared secret. Cons: Still requires a certificate stored locally. Partial Secret Zero improvement only. Adds Azure dependency for a local workstation bootstrap. Overkill for this use case.

Option 4: Accept current state (plaintext in ~/.bash_profile)

Pros: Already working. Zero implementation effort. Cons: Plaintext credential on disk. Cannot commit to git. Manual step on rebuild.

Decision

Deferred — Option 1 (secret-tool / Linux OS Keyring) is the target state.

Implementation blocked on WSL systemd / keyring daemon viability testing. Current state (Option 4) accepted as interim with the following mitigations:

  • ~/.bash_profile committed to git with REPLACE_ME placeholder for client secret
  • Runbook: retrieve new client secret from Infisical UI → Access Control → Identities → alienware-wsl → Universal Auth → Add Client Secret
  • Client secret regenerated on each workstation rebuild (old secret deleted)
  • Full-disk encryption on CanEast AI Node assumed active

Consequences

  • Secret Zero risk acknowledged and documented
  • AKV evaluated and ruled out for this specific use case (on-prem workstation)
  • AKV remains on roadmap for Azure-hosted Terraform workload secrets (future ADR)
  • Implementation WI raised to test secret-tool on WSL and update DEV-0002 bootstrap script accordingly

References

  • DEV-0002 — CanEast AI Node workstation-as-code (bootstrap script alienware-setup.sh)
  • IAM-0001 — Infisical secrets management (Machine Identity Universal Auth)
  • WSL systemd support: https://learn.microsoft.com/en-us/windows/wsl/systemd