Audit CLI guardrails before GA
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
- Ambito
- cli, documentation, security
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:
- Every protection offered can be enforced, or is clearly documented as a guardrail only.
- No docs, help text, or error messages suggest a CLI-level control is a security boundary.
- 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
- Catalog all guardrails the CLI provides.
- 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.
- Open issues with any fixes or improvements discovered in step 2.
- 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
- Improve warnings and errors:
- Warn when a context with a
commands.allowedlist shares a config file with credentials for other contexts. - Link
command_blockederrors to the guidance above. - Update
elastic helptopics anddocs/cli/configuration_reference.mdto say "guardrail", not "security".
- Warn when a context with a
- 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
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di elastic/cli
-
feat: ship skills/elastic/SKILL.md for agent invocationForse già presa @onatozmenn l’ha presa 13 giorni fa. Apertaenhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
elastic/cli#628 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
elastic/cli#617 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 Mezza giornata Idoneità per principianti 62/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 20/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 70/100
I maintainer di solito rispondono entro 1 giorno
Issue simili
-
awaiting-response bug needs-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
wildcard/caro#1562 · 1 commento ·
I maintainer di solito rispondono entro 3 giorni
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 72/100
supadata-ai/mcp#27 ·
-
content
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
cosimochellini/one-piece-zero-spoiler#516 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
capricorn86/happy-dom#2485 ·
I maintainer di solito rispondono entro 2 giorni
-
lane: fast
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
unicef/adt-studio#946 ·
I maintainer di solito rispondono entro 2 giorni