Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Audit CLI guardrails before GA

Aperta
#722 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
57/100
Tipo di issue
Documentazione
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript

Direzione di ricerca

Start by locating where guardrails live: per-context commands.allowed/deny policies, the allow_context_override lock from #718, and the command_blocked error. Catalog them against the goal, then check docs/cli/configuration_reference.md, elastic help topics, and error/warning strings for language implying a security boundary. Done means each guardrail is classified enforceable/guardrail-only/misleading, docs say "guardrail", and follow-up issues or doc updates exist for anything misleading.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

The CLI ships several config-level guardrails, such as per-context command allow/deny policies and the allow_context_override lock proposed in #718. I'm concerned that they give CLI config authors a false sense of security.

The CLI runs as the same OS user as the caller, whether that caller is a person or an agent. Any control that lives in the CLI or its config file can be bypassed by someone with that access. The bypasses include:

  • reading API keys straight from the config file and calling the API with curl
  • setting ELASTIC_CLI_CONFIG_FILE
  • writing a new config file
  • editing the existing config file

Complete protection comes from outside the CLI:

  • Server-side authorization: scope auth credentials to least privilege
  • OS-level isolation: root-owned config files, containers, VMs. Credentials the caller shouldn't use don't belong in a file they can read.

Goal

Before the CLI reaches GA, we need to audit and discuss CLI guardrails that have been implemented to ensure:

  1. Every protection offered can be enforced, or is clearly documented as a guardrail only.
  2. No docs, help text, or error messages suggest a CLI-level control is a security boundary.
  3. Docs and error messages point CLI users to true security controls.

Non-goal: removing useful guardrails. They still help prevent mistakes. They just shouldn't be sold as any more than that. Anywhere guards introduce complexity increases the cost of maintenance.

Proposed work

  1. Catalog all guardrails the CLI provides.
  2. For each guardrail, decide which of these it is:
    • Enforceable: it protects against something the CLI controls (input validation, confirmation).
    • Guardrail only: prevents accidents or misuse, but can be bypassed by a caller with the same permissions.
    • Misleading: its name or docs imply more than it delivers.
  3. Open issues with any fixes or improvements discovered in step 2.
  4. Add documentation encouraging security best practices, including:
    • scoped API keys
    • keeping creds for off-limits contexts where the user cannot reach them
    • OS-level isolation
  5. Improve warnings and errors:
    • Warn when a context with a commands.allowed list shares a config file with credentials for other contexts.
    • Link command_blocked errors to the guidance above.
    • Update elastic help topics and docs/cli/configuration_reference.md to say "guardrail", not "security".
  6. Consider building a CLI helper for creating restricted API keys that can be stored in an isolated agent context, to promote more appropriate solutions to concerns like #700.
Lingua principale
TypeScript
Stelle
47
Fork
27
Merge medio
2g 3h
PR unite (30g)
55

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di elastic/cli

Tutte le issue di elastic/cli

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.