GitLab で AWS Secrets Manager を使用する
AWS Secrets Manager は GitLab と統合されています。Secrets Manager シークレットを活用して GitLab 認証情報を保護し、GitLab でハードコードされなくなるようにします。代わりに、アプリケーションが GitLab CI/CD パイプラインでジョブを実行すると、GitLab Runner
この統合を使用するには、IAM AWS Identity and Access Management と IAM ロールに OpenID Connect (OIDC) ID プロバイダーを作成します。これにより、GitLab Runner は Secrets Manager シークレットにアクセスできるようになります。GitLab CI/CD と OIDC の詳細については、GitLab のドキュメント
考慮事項
非公開の GitLab インスタンスを使用している場合、この Secrets Manager 統合を使用することはできません。代わりに、非パブリックインスタンスに関する GitLab のドキュメント
前提条件
Secrets Manager を GitLab と統合するには、次の前提条件を完了します。
-
AWS Secrets Manager シークレットを作成する
GitLab ジョブで取得され、これらの認証情報をハードコードする必要がなくなる Secrets Manager シークレットが必要です。GitLab パイプラインを設定するときは、Secrets Manager シークレット ID が必要です。詳細については「AWS Secrets Manager シークレットを作成する」を参照してください。
-
IAM コンソールで GitLab を OIDC プロバイダーにします。
このステップでは、IAM コンソールで GitLab を OIDC プロバイダーにします。詳細については、OpenID Connect (OIDC) ID プロバイダーの作成」およびGitLab ドキュメント
」を参照してください。 IAM コンソールで OIDC プロバイダーを作成するときは、次の設定を使用します。
-
provider URLを GitLab インスタンスに設定します。例えば、gitlab.example.comです。 -
audienceまたはaudをsts.amazonaws.comに設定します。
-
-
IAM ポリシーとロールを作成する
IAM ロールとポリシーを作成する必要があります。このロールは AWS Security Token Service (STS) を使用する GitLab によって引き受けられます。詳細については、「カスタム信頼ポリシーを使用してロールを作成する」を参照してください。
-
IAM コンソールで、IAM ロールを作成するときに次の設定を使用します。
-
Trusted entity typeをWeb identityに設定します。 -
Groupをyour GitLab groupに設定します。 -
ステップ 2 で使用したものと同じプロバイダー URL (GitLab インスタンス) に
Identity providerを設定します。 -
ステップ 2 で使用したものと同じ対象者に
Audienceを設定します。
-
-
次に示すのは、GitLab がロールを引き受けることを許可する信頼ポリシーの例です。信頼ポリシーには、AWS アカウント、GitLab URL、およびプロジェクトパス
がリストされている必要があります。 -
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRoleWithWebIdentity", "Principal": { "Federated": "arn:aws:iam::111122223333:oidc-provider/gitlab.example.com" }, "Condition": { "StringEquals": { "gitlab.example.com:aud": [ "sts.amazon.com" ] }, "StringLike": { "gitlab.example.com:sub": [ "project_path:mygroup/project-*:ref_type:branch-*:ref:main*" ] } } } ] }
-
また、GitLab に AWS Secrets Manager へのアクセスを許可する IAM ポリシーを作成する必要があります。このポリシーを信頼ポリシーに追加できます。詳細については、「IAM ポリシーを作成する」を参照してください。
-
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "secretsmanager:GetSecretValue", "Resource": "arn:aws:secretsmanager:us-east-1:111122223333:secret:your-secret" } ] }
-
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 変数
以下は、GitLab CI/CD 設定ファイルの YAML ファイルのスニペットです。
variables: AWS_REGION:us-east-1AWS_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 設定をテストできます。詳細については、「OIDC 設定のテストに関する GitLab のドキュメント
トラブルシューティング
以下は、Secrets Manager を GitLab と統合するときに発生する可能性がある一般的な問題のトラブルシューティングに役立ちます。
GitLab Pipeline の問題
GitLab パイプラインの問題が発生した場合は、以下を確認してください。
-
YAML ファイルが適切にフォーマットされている。詳細については、「GitLab のドキュメント
」を参照してください。 -
GitLab パイプラインが正しいロールを引き受けており、適切なアクセス許可と正しい AWS Secrets Manager シークレットへのアクセスを持っている。
その他のリソース
以下のリソースは、GitLab と AWS Secrets Manager に関する問題のトラブルシューティングに役立ちます。