[Feature Request] Strip ambient credential variables a plugin knows about, not only declared @internal items

Open
  • Is something wrong?
#1,144 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
38/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
typescript
Domain
cli, security

Research direction

Start by reading how @internal items are handled and how plugins register their metadata; the issue does not name source files or tests. Decide how plugin-known ambient credentials and an optional generic strip mechanism should interact with explicit schema declarations, then define completion around the reproduction: OP_SERVICE_ACCOUNT_TOKEN is absent from the child environment when the 1Password plugin is loaded, with the documented override behavior covered.

Written by the indexing model from the issue text.

Description

Description

@internal keeps a secret-zero out of the child process, but only for items the schema declares. A credential that is already in the environment under another name reaches the app unchanged. Ask: let plugins declare the credential env vars they use, so varlock run strips them too, and/or add a way to strip named vars from the child (for example a root decorator or varlock run --strip VAR).

Motivation

With the 1Password plugin, the documented setup declares the token as OP_TOKEN (@type=opServiceAccountToken, internal by default). But the op CLI and 1Password's own docs use OP_SERVICE_ACCOUNT_TOKEN, so hosts and shells often carry that name too. Repro on 1.21.0:

.env.schema:

# @plugin(@varlock/1password-plugin)
# @initOp(token=$OP_TOKEN, allowAppAuth=false, useCliWithServiceAccount=true)
# @defaultSensitive=false
# ---
# @type=opServiceAccountToken @internal @optional
OP_TOKEN=
API_URL=https://api.example.com

OP_SERVICE_ACCOUNT_TOKEN=dummy varlock run -- sh -c 'env | grep ^OP_'
# OP_SERVICE_ACCOUNT_TOKEN=dummy

The app, and anything it spawns, can read every vault that token opens, while the schema looks like it keeps the secret-zero internal.

Declaring it yourself works (OP_SERVICE_ACCOUNT_TOKEN= with @internal @optional removes it from the child), but you have to know that name, and the same applies to every plugin's credential variables (AWS keys, Vault tokens, and so on).

Proposed Solution
  • A plugin can register the ambient credential variables it knows about (OP_SERVICE_ACCOUNT_TOKEN, OP_CONNECT_TOKEN for 1Password), and varlock treats them as @internal whenever that plugin is loaded, unless the schema explicitly declares them non-internal.
  • Optionally a generic mechanism, e.g. # @stripFromChild(OP_SERVICE_ACCOUNT_TOKEN, AWS_SECRET_ACCESS_KEY) or varlock run --strip, for tokens no plugin knows about.
  • varlock load could warn when a known credential variable is present but not declared.
Alternatives
  • Declare each such variable as @internal @optional in every schema (works today, easy to forget).
  • Wrap the app with env -u (outside varlock, and does nothing for auto-load).
Additional Information

Related to the secret-zero guidance in the 1Password plugin docs and the @internal item decorator.

Dominant language
TypeScript
Stars
4.9k
Forks
140
Avg merge
2d 3h
Merged PRs (30d)
35

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dmno-dev/varlock

All issues in dmno-dev/varlock

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.