teleport-acl-lifecycle

Teleport 访问列表生命周期

使用此技能为用户授予对特定 Teleport 资源的访问权限。浏览可用的服务器、数据库、应用、Kubernetes 集群等，选择要授予访问权限的资源以及用户连接这些资源的方式，然后创建、更新或停用授予该访问权限的访问列表。

首先选择路由

运行命令前，必须先选择且仅选择一个路由，然后只阅读该路由引用的文件：

用户意图	示例	操作
仅列出资源	“列出 AWS IC”、“显示应用”、“数据库有哪些标签？”、“集群中有哪些资源？”	阅读 RESOURCE_KINDS.md 和 SECURITY.md。仅列出资源、标签和分配；暂不起草、创建或更新。
创建新列表	“让 alice 访问应用”、“创建 Prod SSH 访问列表”、“bob 需要 AWS IC”	阅读 CREATE.md、RESOURCE_KINDS.md、PRESETS.md、SCOPES.md 和 SECURITY.md。如果创建部分成功，需要清理或处理未使用的角色，还要阅读 LEFTOVER_ROLES.md。
更新现有列表	“将 bob 添加到 Prod Apps”、“将 AWS IC 添加到现有列表”、“重命名列表”、“移除应用访问权限”	阅读 UPDATE.md、RESOURCE_KINDS.md、PRESETS.md、LEFTOVER_ROLES.md、SCOPES.md 和 SECURITY.md。
删除现有列表	“删除”、“移除此列表”、“停用”、“拆除”	阅读 DELETE.md、PRESETS.md、LEFTOVER_ROLES.md、SCOPES.md 和 SECURITY.md。

如果路由不明确，询问用户是想查看可用资源、创建新的访问列表、更新现有访问列表，还是删除现有访问列表。

如果用户要求创建访问列表，但未提供访问目标，例如“创建一个访问列表”，则选择创建路由，并显示 CREATE.md 中的 Generic Missing Access Target Prompt。

如果用户提到需要访问权限的人员，但未提供目标，例如“让 Alice 和 Bob 获得访问权限”，则选择创建路由，并以便于首次使用的方式询问资源。不要先提“访问列表”、“授权目标”、“UUID”或所有者。显示 CREATE.md 中的 Vague Access Prompt。

如果用户提到了人员和目标，但没有明确要求创建访问列表，例如“授予 claudia 应用访问权限”，则选择创建路由，并遵循 CREATE.md 中的 plain-language access bridge。

关键注意事项

• 列出资源不等于创建或更新资源。 如果用户要求列出、显示或检查资源，不要起草、创建或更新访问列表。
• 不要凭记忆选择资源命令。 使用 RESOURCE_KINDS.md 中的确切命令矩阵。
• AWS IC 比较特殊。 它的列表命令没有 --query 标志；请使用 $TCTL integrations awsic accounts ls --format=json，并根据每条返回记录构建准确的 accountID^permissionSetARN 分配项。AWS IC 授权使用 --aws-ic-assignments，而非 --app-labels。
• 显示标题不是 CLI 标识符。 更新或删除现有列表需要使用访问列表标识符，而且标题并不唯一——在执行任何 acl get、acl update 或 acl rm 之前，先按照 SECURITY.md 的重复标题规则进行确认。
• 分离父级关联需要单独写入。 用户确认永久删除，并不代表批准之后发现的父级更新——请参见 DELETE.md 中的 Parent Nesting。
• 访问类型不可变。 以 standing、Access Request（access-request）或 custom 创建的列表无法原地转换；请重新创建。请根据 access-list-preset 标签判断，而非 spec.type——请参见 PRESETS.md 的 Existing Lists 部分。
• 列表类型决定允许使用的标志。 访问类型列表使用资源标志，并拒绝授权标志；自定义列表使用授权标志，并拒绝资源标志和 --remove-access——请参见 UPDATE.md 的 Legal Changes。
• 更新成员/所有者标志会替换集合，而非合并。 单独更改成员时，请改用 tctl acl users add/rm——请参见 UPDATE.md 的 Replace Traps。
• 准确保留标识符的大小写。 用户名、登录名、主体、角色名称和特征值都区分大小写。传入 tctl 标志时，必须完全按照用户输入的内容填写，即使为便于阅读而在周围文字中将名称首字母大写——“give alice access”表示成员值是 alice，而不是 Alice。
• 绝不要凭目测解读原始 tctl 输出。 输出可能很大，也可能被截断——先完整捕获 JSON，再通过筛选器检查，遵循 SECURITY.md 中的 Read Capture Discipline。

在草稿中使用这些标记：(need one)、← default、← guessed for approval 和 (optional, ask)。

呈现

使用 Markdown 结构呈现结构化输出，绝不能写成一大段。 tctl JSON 和你自己的草稿都必须整理成便于浏览的格式。

• 资源列表： 使用 Markdown 表格，每项资源占一行。使用路由加载的该资源类型对应列。不要在句子中连续输出资源。列表中不要包含选择器预览警告。

• 选择确认： 对于可预览的、按标签选择的授权，使用 Markdown 表格展示预览匹配项和路由加载的警告。对于用户明确指定的模式选择器，遵循 RESOURCE_KINDS.md 的无预览确认要求；不要将表格用作其匹配预览。

• 草稿、变更和审批： 使用简短的 Markdown 标签列表，或两列表格（field | value）。包含适用字段，例如目标、类型、所有者、成员、授权目标、预览、警告、移除项和命令意图，每个字段单独一行。若命令意图不止一项，不要将它们塞进单个表格单元格；绝不要使用 <br> 或其他 HTML 在单元格内伪造换行。将每条命令分别列在表格下方的围栏 bash 代码块中。

• 问题与选项： 按照路由的阶段进行。只询问当前阶段尚缺的问题，然后等待用户回答。用户回答当前问题之前，不要预览或叙述其他尚未回答的问题。

  命名参考菜单是由其参考文件定义的固定 Markdown 菜单，不属于结构化问题工具选项。必须完整地以纯 Markdown 呈现，不得截断、分页、合并、省略、改写或压缩成选择器。每当询问访问目标／资源类型时，都包括 RESOURCE_KINDS.md 中的 Resource Offer List；也包括 RESOURCE_KINDS.md 中的列表完成后续操作菜单。若准备显示 ☐ Access target，请改为以纯 Markdown 呈现 Resource Offer List。

  在有结构化问题工具可用时，对小型的阶段性选项或字段组使用该工具，例如长期授权还是 Access Request，或所有者／标题／描述／成员。每个字段或选项单独提问。

  如果没有结构化问题工具可用，请使用纯 Markdown，每个字段或选项单独占一行。不要在一个句子中串联多个问题。

  不佳示例：“谁来负责，标题和描述是什么，成员有哪些？”

  良好示例（纯 Markdown 格式）：

  • 所有者（谁负责管理／审核此列表）？
  • 标题？
  • 描述（可选）？
  • 成员（可以稍后指定）？

• 多个部分之间空一行；如果消息包含多个部分，请使用简短的粗体标题或 ## 标题。

• 仅使用文字说明解释内容或警告；数据应放在 Markdown 表格或列表中。

设置

查找 tctl（which tctl、/usr/local/bin/tctl、/opt/homebrew/bin/tctl、~/go/bin/tctl），并设置 TCTL=<path>。在工作站上，tctl 使用当前的 tsh login；在认证服务器上，它使用本地管理员身份。如果 tctl 返回 access denied，请将错误作为数据转达，并指出可能需要的权限类别：access_list 写入权限，以及处理访问类型角色时所需的 role 访问权限。