Cloud/設定/サービスアカウント

サービスアカウント

VinkiusについてAIに質問

マシンのための ID です。自動化、CI/CD パイプライン、OIDC ワークロード向けの人間でないアカウントで、ローテーション可能なキーを持ち、人間は紐付いていません。

Service Accounts は、メンバーリストでは答えられない問いに答えます: あなたの自動化はどの ID を使うのか? 説明は "Non-human identities for automations, CI/CD and OIDC workloads." 管理には org:manage が必要です。

R

Service Accounts

Non-human identities for automations, CI/CD and OIDC workloads.

ci-deployerStatic key
Rotate keyDelete
vsk_live_••••••••3f9aCreated Mar 2025
github-actionsOIDC workload
Rotate keyDelete
federatedCreated Jun 2025
Create service account
Service Accounts, live. Non-human identities with static keys or OIDC workload identity, key reveal and deletion.

モックアップが実際の画面です。静的キーをローテーションして新しいキーを表示させてみてください。また、キーを一切持たない OIDC ワークロードアカウントに注目してください。

2 種類の ID

Create service account では両方の種類を作成できます:

  • Static key: アカウントが生成されたキーを保持します。キーは "Service account key" の下に一度だけ表示され、その後はマスクされます。Secret で認証するスクリプトやパイプライン向けです。古いキーが漏えいした可能性があるときは、Rotate key で新しいキーを発行できます;
  • OIDC ワークロード ID: 保存された Secret は一切ありません。自動化は自身の OIDC プロバイダー経由で正体を証明し (典型例は GitHub Actions)、組織はその証明を信頼します。漏えいするものも、ローテーションするものもありません。

アカウントごとに 1 行

各アカウントには、名前、種類、マスクされたキーまたはフェデレーションのマーク、作成日時が表示されます。Delete service account は ID をそのまま削除します。それを使っているすべての自動化が認証できなくなるため、ボタンが確認ダイアログの背後にあるのはまさにそのためです。

このページが存在する理由

パイプラインを個人のアカウントで実行すべきではありません。その人が退職した日、デプロイはその人の資格情報とともに止まります。Service Accounts はマシンに固有の名前、固有のキー、固有のライフサイクルを与え、Members の人間とは切り離します。これが、組織の自動化を人事異動から守る仕組みです。

次に読むべきページ

API Keys は姉妹の画面です: 組織のリソースへのプログラマティックアクセスのための、スコープ付きキーを扱います。