クラウドサービスに接続する

プラン: Free、Premium、Ultimate
提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

CI_JOB_JWTとCI_JOB_JWT_V2は、GitLab 15.9で非推奨となり、GitLab 17.0で削除される予定です。代わりにIDトークンを使用してください。

GitLab CI/CDは、OpenID Connect（OIDC）をサポートし、ビルドおよびデプロイジョブがクラウド認証情報とサービスにアクセスできるようにします。従来、チームはシークレットをプロジェクトに保存するか、GitLab Runnerインスタンスに対する権限を適用してビルドおよびデプロイしていました。OIDC対応のIDトークンは、CI/CDジョブで構成可能であり、スケーラブルで最小特権のセキュリティアプローチに従うことができます。

GitLab 15.6以前は、IDトークンの代わりにCI_JOB_JWT_V2を使用する必要がありますが、カスタマイズできません。

前提要件

GitLabのアカウント
認可を構成し、ロールを作成するために、OIDCをサポートするクラウドプロバイダーへのアクセス。

IDトークンは、以下を含むOIDCを持つクラウドプロバイダーをサポートします:

AWS
Azure
GCP
HashiCorp Vault

OIDCを構成すると、すべてのパイプラインのターゲット環境へのJWTトークンアクセスが可能になります。OIDCをパイプライン用に構成する場合は、追加のアクセスに焦点を当てて、パイプラインのソフトウェアサプライチェーンセキュリティレビューを完了する必要があります。サプライチェーン攻撃の詳細については、DevOpsプラットフォームがサプライチェーン攻撃から保護するのにどのように役立つかを参照してください。

ユースケース

GitLabグループまたはプロジェクトにシークレットを保存する必要がなくなります。一時的な認証情報は、OIDCを介してクラウドプロバイダーから取得できます。
グループ、プロジェクト、ブランチ、タグなどのきめ細かいGitLab条件で、クラウドリソースへの一時的なアクセスを提供します。
環境への条件付きアクセスを使用して、CI/CDジョブで職務分離を定義できます。従来、アプリは、ステージング環境または本番環境へのアクセスのみを持つ、指定されたGitLab Runnerでデプロイされていた可能性があります。これにより、各マシンが専用の権限を持つため、Runnerが乱立するようになりました。
インスタンスRunnerが複数のクラウドアカウントに安全にアクセスできるようになります。アクセスはJWTトークンによって決定されます。これは、パイプラインを実行しているユーザーに固有のものです。
デフォルトで一時的な認証情報を取得することにより、シークレットをローテーションするロジックを作成する必要がなくなります。

クラウドサービスのIDトークン認証

各ジョブは、トークンペイロードを含むCI/CD変数として提供されるIDトークンで構成できます。これらのJWTは、AWS、Azure、GCP、VaultなどのOIDCサポート対象のクラウドプロバイダーで認証するために使用できます。

認可ワークフロー

%%{init: { "fontFamily": "GitLab Sans" }}%%
sequenceDiagram
accTitle: Authorization workflow
accDescr: The flow of authorization requests between GitLab and a cloud provider.

    participant GitLab
    Note right of Cloud: Create OIDC identity provider
    Note right of Cloud: Create role with conditionals
    Note left of GitLab: CI/CD job with ID token
    GitLab->>+Cloud: Call cloud API with ID token
    Note right of Cloud: Decode & verify JWT with public key (https://gitlab.com/oauth/discovery/keys)
    Note right of Cloud: Validate audience defined in OIDC
    Note right of Cloud: Validate conditional (sub, aud) role
    Note right of Cloud: Generate credential or fetch secret
    Cloud->>GitLab: Return temporary credential
    Note left of GitLab: Perform operation

クラウド（たとえば、AWS、Azure、GCP、Vault）でOIDCIdentity Providerを作成します。
グループ、プロジェクト、ブランチ、またはタグにフィルタリングする条件付きロールをクラウドプロバイダーで作成します。
CI/CDジョブには、JWTトークンであるIDトークンが含まれています。このトークンを使用して、クラウドAPIで認可できます。
クラウドはトークンを検証し、ペイロードから条件付きロールを検証し、一時的な認証情報を返します。

OIDCクレームを使用した条件付きロールの構成

GitLabとOIDCの間の信頼を構成するには、JWTに対してチェックする条件付きロールをクラウドプロバイダーに作成する必要があります。条件は、JWTに対して検証され、オーディエンスとサブジェクトの2つのクレームに対して特に信頼が作成されます。

オーディエンスまたはaud: IDトークンの一部として構成されます:

job_needing_oidc_auth:
  id_tokens:
    OIDC_TOKEN:
      aud: https://oidc.provider.com
  script:
    - echo $OIDC_TOKEN

サブジェクトまたはsub: グループ、プロジェクト、ブランチ、タグを含むGitLab CI/CDワークフローを記述するメタデータの連結。subフィールドは、次の形式です:
- project_path:{group}/{project}:ref_type:{type}:ref:{branch_name}

フィルターの種類	例
任意のブランチへのフィルター	ワイルドカードがサポートされています。`project_path:mygroup/myproject:ref_type:branch:ref:*`
特定のプロジェクト、mainブランチへのフィルター	`project_path:mygroup/myproject:ref_type:branch:ref:main`
グループ内のすべてのプロジェクトへのフィルター	ワイルドカード</wildカードがサポートされています。`project_path:mygroup/*:ref_type:branch:ref:main`
Gitタグへのフィルター	ワイルドカードがサポートされています。`project_path:mygroup/*:ref_type:tag:ref:1.0`

お使いのクラウドプロバイダーによるOIDC認可

クラウドプロバイダーとの接続については、次のチュートリアルを参照してください: