自動化とアクセストークンのガイドライン
概要
トークン管理は GitLab が使用するさまざまなシステムとサブシステム内での認証と認可を提供するために重要です。トークン概要は GitLab で使用されるトークンの特定を助けます。承認されたトークンの使用と配布についてはトークン管理標準を参照してください。
自動化とアクセストークンのガイドライン
gitlab-org グループとその下のプロジェクトの自動化は3つのカテゴリに分けられます:
- プロジェクト内のリポジトリ、パッケージ、コンテナレジストリの自動化: プロジェクトデプロイトークンで十分です。
- プロジェクト内の API を通じた自動化: プロジェクトアクセストークンで十分です。
- グループ内の API を通じた自動化: グループアクセストークンで十分です。
これらのガイドラインは、最小権限の原則に沿った承認された安全なパターンを使用してエンジニアリング自動化の一貫性を確保します。
マージリクエスト自動化ガイドライン
gitlab-org 下のプロジェクトでマージリクエストを開く自動化は、エンジニアリング PI に影響を与える可能性のあるボット作成 MR のより明確な測定のために ~"automation:bot-authored" ラベルを適用する必要があります。
アクセストークンのベストプラクティス
既存のトークンを再利用しない
トークンが何に使用されているかを追跡しにくくなるため、自分の自動化に既存のトークンを再利用しないでください。また、トークンが失効した場合に必要な変更の数が増えます。
デフォルトではプロジェクトアクセストークンを使用する
デフォルトとして、また可能な場合は常に、任意の API 自動化のために新しいプロジェクトアクセストークンを作成し、以下のガイドラインに従ってください:
- アクセストークンに適切な名前を作成してください。これはトークン用に作成されるボットユーザーの名前にもなることに注意してください。
- 一時的な自動化であっても、常にトークンに有効期限を設定してください。
- 自動化が必要とする最小スコープをトークンに付与してください（通常は
apiスコープ）。
プロジェクトアクセストークンにはいくつかの既知の制限がありますが、それを試すことで機能の改善にのみ役立ちます。
リポジトリ、パッケージ、コンテナレジストリの自動化にはプロジェクトデプロイトークンを使用する
リポジトリ、パッケージ、またはコンテナレジストリの自動化のために新しいプロジェクトデプロイトークンを作成してください。
プロジェクトアクセストークンと同じガイドラインに従ってください。
プロジェクトアクセストークンが使用できない場合は特定のサービスアカウントトークンを使用する
自動化がグループレベルまたは複数のプロジェクトにわたって適用され、自動化を実行するためにメンテナー権限が必要な場合（例えば、制限されたクイックアクションを投稿するため）は、特定のチームが所有する新しいサービスアカウントをリクエストすることができます。
現在稼働中の自動化リスト
GitLab はエンジニアリングプロセスを合理化するために自動化を使用しています。例えば:
- マージリクエストの衛生管理のための Danger bot。Danger bot グループアクセストークンを使用しています。
- Issue とマージリクエストの自動化のための Triage ops:
- スケジュールされたリマインダーと Issue とマージリクエストのレポート。サービスアカウントが必要です。
- Issue とマージリクエストのイベントへのリアルタイムの反応。サービスアカウントが必要です。
- Allure テストレポート。エンドツーエンドテストに対してレビューアプリを実行するマージリクエストに Allure テストレポートを投稿するために End-to-end tests Allure report プロジェクトアクセストークンを使用しています。
- 非同期レトロスペクティブ生成。機密 Issue のフェッチを除きプロジェクトアクセストークンを使用できます。
- GitLab Runner リリース。サービスアカウントが必要です。
- リポジトリのミラーリング。サービスアカウントが必要です。
現在および潜在的な GitLab.com サービスアカウント
@gitlab-botはエンジニアリング生産性チームが所有しており、様々なことを実行しています。これを複数の専用サービスアカウントに分解中です。@gitlab-qaはDeveloper Experience ステージが所有しており、エンドツーエンドテスト関連の自動化を実行しています。@gitlab-release-tools-botはDelivery チームが所有しており、デリバリー/リリース関連の自動化を実行しています。@gl-build-triggerはDistribution グループが所有しており、ビルド関連のパイプラインをトリガーしています。@gitlab-omnibus-mirror-botはDistribution グループが所有しており、gitlab-org/omnibus-gitlabプロジェクトのさまざまな依存関係プロジェクトをミラーリングしています。gitlab-org/quality/triage-ops、gitlab-org/gitlab-triageのトリアージ操作はエンジニアリング生産性チームが所有しています。
単一の @gitlab-bot サービスアカウントの背景
以前は、ほぼすべての自動化プロセスに使用する単一の @gitlab-bot サービスアカウントがありました。
これには2つの主な欠点がありました:
- ボットが API レート制限に達した場合、レート制限を無効にしなければなりませんでした。これは無限ループスクリプトが自社の API に対するサービス拒否（DoS）につながる可能性を意味しました。
- セキュリティ上の懸念がありました:
- 同じトークンをあらゆる場所で再利用すると、トークンが漏洩して回転する必要がある場合に多くの混乱が生じます。
- サービスアカウントの認証情報はエンジニアリング部門全体がアクセスできました。誰でもボットのアカウントにログインして自分のアクセストークンを作成できました。
現在、以下を進めています:
- トークンのセルフサービス作成を停止するために
@gitlab-botサービスアカウントの認証情報をエンジニアリング生産性 1Password ボールトに移動する。 - 可能な場合はプロジェクトアクセストークンに、その他の場合は特定のサービスアカウントに現在の
@gitlab-botのトークンを移行する。
