Skip to content

rfc: 1Password CLI secret injection - #127

Open
BoldBlackBot wants to merge 1 commit into
boldblackai:mainfrom
BoldBlackBot:rfc/1password-secret-injection
Open

rfc: 1Password CLI secret injection#127
BoldBlackBot wants to merge 1 commit into
boldblackai:mainfrom
BoldBlackBot:rfc/1password-secret-injection

Conversation

@BoldBlackBot

Copy link
Copy Markdown
Contributor

Summary

Adds rfcs/2026-07-15_1password-secret-injection.md — an RFC proposing that harness resolve 1Password secret references (op://vault/item/field) in env files, so secrets like GH_TOKEN and provider API keys no longer need to sit in plaintext .env files on disk.

Can op reach the host vault from the container?

No — the 1Password desktop-app integration uses a local IPC socket that does not cross the container boundary. This is a documented 1Password limitation. The RFC covers the two container-compatible auth modes (service-account token, and 1Password Connect) and explains why the socket path is a non-starter.

Design

The RFC analyzes two structurally different resolution points and recommends one:

  • Option A — host-side resolution (recommended, default). harness resolves op:// references on the host at launch time (using the host op CLI, which can use desktop integration), writes resolved values to a mktemp + chmod 600 temp file, passes it into the container via the existing --env-file flow, and scrubs it after start. No image/entrypoint change; the vault token never enters the container. Degrades gracefully — no op:// references → no op needed on the host.
  • Option B — in-container resolution (service account / Connect). Documented as an alternative for headless CI. Trades a broader blast radius (a vault token inside the container) for no host op dependency.

Why

Plaintext .env files on disk are an accidental-commit and supply-chain-exfiltration risk (postinstall scripts, MCP servers, and agents all run arbitrary code with read access to the workspace). Storing the reference instead of the value makes the on-disk file useless to an attacker.

What changed

  • rfcs/2026-07-15_1password-secret-injection.md (new) — the RFC.

No code, image, or entrypoint changes; this is a proposal for review. Lints clean against the repo markdownlint-cli2 config.

Checklist

  • RFC follows the repo format (rfcs/YYYY-MM-DD_short_title.md)
  • pnpm lint:md passes (0 errors)
  • Review + decision on Option A vs B

@BoldBlackBot
BoldBlackBot force-pushed the rfc/1password-secret-injection branch 3 times, most recently from 53fa79d to b16704f Compare August 3, 2026 13:31
@BoldBlackBot
BoldBlackBot force-pushed the rfc/1password-secret-injection branch 2 times, most recently from 1be3c3d to 82d9cb2 Compare August 11, 2026 13:31
Add an RFC proposing host-side resolution of 1Password secret references
(op://vault/item/field) in env files, so secrets like GH_TOKEN and provider
API keys no longer need to sit in plaintext .env files on disk. Documents why
the op desktop-app socket cannot cross the container boundary and recommends
Option A (host-side resolution) over in-container service-account/Connect auth
to keep the vault token off the container's attack surface.

Co-authored-by: Julio Capote <capotej@users.noreply.github.com>
@BoldBlackBot
BoldBlackBot force-pushed the rfc/1password-secret-injection branch from 82d9cb2 to 7b0a852 Compare August 11, 2026 21:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant