Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Audit CLI guardrails before GA

未关闭
  • 哪里不对？
#722 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
57/100
Issue 类型
文档
描述清晰度
基本清楚
活跃度
活跃
技术栈
typescript
领域
cli, documentation, security

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

tracking

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.
主要语言
TypeScript
星标
51
派生
27
平均合并
1 天 19 分钟
30 天内合并 PR
50

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

elastic/cli 的其他 Issue

查看 elastic/cli 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。