teleport-acl-lifecycle

Teleport アクセスリストのライフサイクル

このスキルを使って、特定の Teleport リソースへのアクセスをユーザーに付与します。利用可能なサーバー、データベース、アプリケーション、Kubernetes クラスターなどを確認し、対象と接続方法を選んでから、そのアクセスを許可するアクセスリストを作成、更新、または廃止します。

最初にルートを選択

コマンドを実行する前に、ルートを必ず1つ選択し、そのルートで参照されているファイルだけを読んでください。

ユーザーの意図	例	実行内容
リソースの一覧表示のみ	"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 も読んでください。
既存のリストを更新	"Prod Appsにbobを追加して"、"既存のリストに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 の平易な表現によるアクセスへの橋渡しに従ってください。

重要な注意点

• リソースの一覧表示は作成・更新ではありません。 ユーザーがリソースの一覧表示、表示、または確認を求めた場合、アクセスリストの下書き、作成、更新を行わないでください。
• 記憶を頼りにリソースコマンドを選ばないでください。 RESOURCE_KINDS.md の正確なコマンド一覧を使用してください。
• AWS IC は特殊です。 一覧表示コマンドに --query フラグはありません。$TCTL integrations awsic accounts ls --format=json を使用し、返された各レコードから正確な accountID^permissionSetARN 割り当てを作成してください。AWS IC の権限付与には --app-labels ではなく、--aws-ic-assignments を使用します。
• 表示タイトルは CLI の識別子ではありません。 既存リストの更新・削除にはアクセスリストの識別子が必要です。また、タイトルは一意ではありません。acl get、acl update、または acl rm を実行する前に、SECURITY.md の重複タイトルに関するルールに従って解決してください。
• 親の切り離しは別個の書き込み操作です。 ユーザーによる完全削除の確認は、後から見つかった親の更新を承認するものではありません。DELETE.md の Parent Nesting を参照してください。
• アクセスの種類は変更できません。 standing、Access Request（access-request）、または custom として作成したリストは、その場で別の種類に変換できません。作り直してください。spec.type ではなく、access-list-preset ラベルで判定してください。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 出力を目視で確認しないでください。 出力は非常に大きく、切り詰められることがあります。SECURITY.md の Read Capture Discipline に従い、まず JSON 全体を取得してから、フィルターを通して確認してください。

下書きでは次のマーカーを使用してください：(need one)、← default、← approval のための推定、(optional, ask)。

表示

構造化された出力は、長い段落ひとつではなく、Markdown の構造を使って表示します。 tctl の JSON と独自の下書きは、どちらも一覧しやすい形に整えます。

• リソース一覧： リソースごとに 1 行の Markdown テーブルを使います。そのリソース種別に応じて、ルートから読み込んだ列を使用します。文中にリソースを連ねて表示しないでください。一覧にセレクターのプレビューに関する警告を含めないでください。

• 選択の確認： プレビュー可能なラベル選択型の許可では、プレビューの一致項目とルートから読み込んだ警告を含む Markdown テーブルを表示します。ユーザーが明示的に指定したパターンセレクターでは、RESOURCE_KINDS.md のプレビューなしの確認手順に従ってください。一致項目のプレビューとしてテーブルを表示しないでください。

• 下書き、差分、承認： 短い Markdown のラベル付きリストか、2 列の Markdown field | value テーブルを使います。該当する場合は、対象、種別、オーナー、メンバー、許可の対象、プレビュー、警告、削除項目、コマンドの意図などを、フィールドごとに 1 行で含めます。コマンドの意図が複数ある場合は、1 つのテーブルセルに詰め込まないでください。セル内の改行を偽装するために <br> やその他の HTML を使用せず、テーブルの下にあるフェンス付き bash コードブロックで、各コマンドを 1 行ずつ記載します。

• 質問と選択肢： ルートの各段階に従います。現在の段階で不足している質問だけをして、ユーザーの回答を待ちます。ユーザーが現在の段階の質問に回答する前に、ほかの未回答の質問をプレビューしたり、説明したりしないでください。

  名前付き参照メニューは、参照ファイルが管理する厳密な Markdown メニューであり、構造化された質問ツールの選択肢ではありません。省略、ページ分割、統合、削除、言い換え、選択肢への圧縮を行わず、プレーンな Markdown で全項目を表示します。これには、アクセス対象／リソース種別を尋ねる際の RESOURCE_KINDS.md の Resource Offer List と、一覧表示後の次のアクションメニューが含まれます。☐ Access target を表示する場合は、代わりに Resource Offer List をプレーンな Markdown で表示してください。

  利用可能な場合は、「常設か Access Request か」や「オーナー／タイトル／説明／メンバー」など、現在の段階に限られた選択肢やフィールドの組み合わせに構造化された質問ツールを使用します。フィールドまたは選択肢ごとに質問を 1 つにします。

  構造化された質問ツールを利用できない場合は、各フィールドまたは選択肢を 1 行ずつ、プレーンな Markdown で記載します。複数の質問を 1 文の中につなげないでください。

  悪い例：「このリストのオーナーは誰ですか。タイトルと説明はどうしますか。メンバーは誰ですか？」

  良い例（プレーンな Markdown 形式）：

  • オーナー（このリストを管理／レビューする人）は誰ですか？
  • タイトルは何ですか？
  • 説明（任意）は何ですか？
  • メンバーは誰ですか？（後から指定できます）

• 複数の部分があるメッセージでは、セクション間に空行を入れ、短い太字の見出しか ## を使います。

• 説明や警告には文章を使い、データは Markdown のテーブルかリストに記載します。

セットアップ

which tctl、/usr/local/bin/tctl、/opt/homebrew/bin/tctl、~/go/bin/tctl で tctl を探し、TCTL=<path> を設定します。ワークステーションでは、tctl は現在の tsh login を使用します。認証サーバーでは、ローカルの管理者 ID を使用します。tctl がアクセス拒否を返した場合は、エラーをデータとして伝え、想定される権限の種類を示します。つまり、access_list の書き込み権限と、アクセス種別のロールを扱う場合は role のアクセス権限です。