Skip to content

Deprecated — Migrated to DEV-0003 on 2026-05-02 per ADR-0047. This source file is retained as a reference; the canonical content is in DEV-0003.

ADR-0032: Workstation Secret Zero -- OS Keyring for Infisical Bootstrap Credential

Date: 2026-04-19 Status: Proposed Area: Platform / Workstation Security Deciders: Ben Peries

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 ADR-0031 (CanEast AI Node workstation-as-code). It works, but it has a known security gap documented during a session 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.

Why Infisical Cannot Store Its Own Bootstrap Secret

The client secret cannot be stored in Infisical because it is the credential required to authenticate to Infisical in the first place. Storing it there creates a circular dependency: you need the secret to get the secret.

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, silently waiting for an interactive browser login prompt suppressed by 2>/dev/null. 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) was evaluated as an alternative bootstrap store. 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 for Terraform secrets strategy.

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. Not applicable at this scale.

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 ADR-0031 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 ADR-0031 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 (ADR-0031 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. Adds friction. 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. Certificate protected by TPM if available.

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)

Document the risk, redact the secret in git, regenerate via Infisical UI on rebuild.

Pros: Already working. Zero implementation effort. Cons: Plaintext credential on disk. Cannot commit to git. Manual step on rebuild. Fails workstation-as-code portability goal.

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 documents: 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
  • AKV remains on roadmap for Azure-hosted Terraform workload secrets (future ADR)
  • Implementation WI raised to test secret-tool on WSL and update ADR-0031 bootstrap script accordingly

References

  • ADR-0031: CanEast AI Node Workstation-as-Code
  • Secret Zero problem: https://securityboulevard.com/2026/03/workload-iam-vs-secrets-management-a-practical-decision-guide/
  • Infisical Machine Identity: Universal Auth
  • WSL systemd support: https://learn.microsoft.com/en-us/windows/wsl/systemd