GitLab AWS Secrets Manager で を使用する - AWS Secrets Manager
考慮事項前提条件GitLab AWS Secrets Manager との統合トラブルシューティング

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

GitLab AWS Secrets Manager で を使用する

AWS Secrets Manager は GitLab と統合されています。Secrets Manager シークレットを活用して GitLab 認証情報を保護し、GitLab でハードコードされなくなります。代わりに、アプリケーションが GitLab CI/CD パイプラインでジョブを実行すると、GitLab Runner は Secrets Manager からこれらのシークレットを取得します。 GitLab

この統合を使用するには、IAM と IAM ロールに OpenID Connect (OIDC) ID プロバイダー AWS Identity and Access Management を作成します。これにより、GitLab Runner は Secrets Manager シークレットにアクセスできます。GitLab CI/CD と OIDC の詳細については、GitLab ドキュメントを参照してください。

考慮事項

非公開の GitLab インスタンスを使用している場合、この Secrets Manager 統合を使用することはできません。代わりに、非パブリックインスタンスについては GitLab のドキュメントを参照してください。

前提条件

Secrets Manager を GitLab と統合するには、次の前提条件を完了します。

  1. AWS Secrets Manager シークレットを作成する

    GitLab ジョブで取得され、これらの認証情報をハードコードする必要がなくなる Secrets Manager シークレットが必要です。GitLab パイプラインを設定するときは、Secrets Manager シークレット ID が必要です。詳細については「AWS Secrets Manager シークレットを作成する」を参照してください。

  2. IAM コンソールで GitLab を OIDC プロバイダーにします。

    このステップでは、IAM コンソールで GitLab を OIDC プロバイダーにします。詳細については、OpenID Connect (OIDC) ID プロバイダーの作成」およびGitLab ドキュメント」を参照してください。

    IAM コンソールで OIDC プロバイダーを作成するときは、次の設定を使用します。

    1. provider URL を GitLab インスタンスに設定します。例えば、gitlab.example.com。

    2. audience または audを に設定しますsts.amazonaws.com。

  3. IAM ポリシーとロールを作成する

    IAM ロールとポリシーを作成する必要があります。このロールはAWS Security Token Service 、 (STS) を使用する GitLab によって引き受けられます。詳細については、「カスタム信頼ポリシーを使用してロールを作成する」を参照してください。

    1. IAM コンソールで、IAM ロールを作成するときに次の設定を使用します。

      • Trusted entity type を Web identity に設定します。

      • Group を your GitLab group に設定します。

      • ステップ 2 で使用したのと同じプロバイダー URL (GitLab インスタンス) Identity providerに設定します。

      • ステップ 2 で使用したのと同じ対象者Audienceに設定します。

    2. また、GitLab へのアクセスを許可する IAM ポリシーを作成する必要があります AWS Secrets Manager。このポリシーを信頼ポリシーに追加できます。詳細については、「IAM ポリシーの作成」を参照してください。

      表示を増やす表示を減らす

GitLab AWS Secrets Manager との統合

前提条件を完了したら、Secrets Manager を使用して認証情報を保護するように GitLab を設定できます。

Secrets Manager を使用するように GitLab パイプラインを設定する

GitLab CI/CD 設定ファイルを以下の情報で更新する必要があります。

  • STS に設定されたトークンの対象者。

  • Secrets Manager シークレット ID。

  • GitLab パイプラインでジョブを実行するときに GitLab Runner が引き受ける IAM ロール。

  • シークレットが保存され AWS リージョン ている 。

GitLab は Secrets Manager からシークレットを取得し、その値を一時ファイルに保存します。このファイルへのパスは、ファイルタイプ CI/CD 変数と同様に、CI/CD 変数に保存されます。

以下は、GitLab CI/CD 設定ファイルの YAML ファイルのスニペットです。

variables:
  AWS_REGION: us-east-1
  AWS_ROLE_ARN: 'arn:aws:iam::111122223333:role/gitlab-role'
job:
  id_tokens:
    AWS_ID_TOKEN:
      aud: 'sts.amazonaws.com'
  secrets:
    DATABASE_PASSWORD:
      aws_secrets_manager:
        secret_id: "arn:aws:secretsmanager:us-east-1:111122223333:secret:secret-name"

詳細については、GitLab Secrets Manager 統合ドキュメントを参照してください。

必要に応じて、GitLab で OIDC 設定をテストできます。詳細については、GitLab ドキュメントで OIDC 設定のテストを参照してください。

トラブルシューティング

以下は、Secrets Manager を GitLab と統合するときに発生する可能性がある一般的な問題のトラブルシューティングに役立ちます。

GitLab Pipeline の問題

GitLab パイプラインの問題が発生した場合は、以下を確認してください。

  • YAML ファイルが適切にフォーマットされています。詳細については、GitLab ドキュメントを参照してください。

  • GitLab パイプラインは正しいロールを引き受けており、適切なアクセス許可と正しい AWS Secrets Manager シークレットへのアクセスを持っています。

その他のリソース

以下のリソースは、GitLab と に関する問題のトラブルシューティングに役立ちます AWS Secrets Manager。