翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# GitLab AWS Secrets Manager で を使用する
AWS Secrets Manager は GitLab と統合されています。Secrets Manager シークレットを活用して GitLab 認証情報を保護し、GitLab でハードコードされなくなるようにします。代わりに、アプリケーションが GitLab CI/CD パイプラインでジョブを実行すると、[GitLab Runner](https://docs.gitlab.com/runner/) は Secrets Manager からこれらのシークレットを取得します。
この統合を使用するには、IAM と [IAM ロールに OpenID Connect (OIDC) ID プロバイダー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html) AWS Identity and Access Management を作成します。これにより、GitLab Runner は Secrets Manager シークレットにアクセスできるようになります。GitLab CI/CD と OIDC の詳細については、「[GitLab ドキュメント](https://docs.gitlab.com/ci/cloud_services/aws/)」を参照してください。
## 考慮事項
非公開の GitLab インスタンスを使用している場合、この Secrets Manager 統合を使用することはできません。代わりに、[非パブリックインスタンスに関する GitLab のドキュメント](https://docs.gitlab.com/ci/cloud_services/aws/#configure-a-non-public-gitlab-instance)を参照してください。
## 前提条件
Secrets Manager を GitLab と統合するには、次の前提条件を完了します。
1.
**AWS Secrets Manager シークレットを作成する**
GitLab ジョブで取得され、これらの認証情報をハードコードする必要がなくなる Secrets Manager シークレットが必要です。[GitLab パイプラインを設定する](#configure-gitlab-pipeline)ときは、Secrets Manager シークレット ID が必要です。詳細については「[AWS Secrets Manager シークレットを作成する](create_secret.md)」を参照してください。
1.
**IAM コンソールで GitLab を OIDC プロバイダーにします。**
このステップでは、IAM コンソールで GitLab を OIDC プロバイダーにします。詳細については、「[OpenID Connect (OIDC) ID プロバイダーの作成](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_providers_create_oidc.html)」および「[GitLab ドキュメント](https://docs.gitlab.com/ci/cloud_services/aws/)」を参照してください。
IAM コンソールで OIDC プロバイダーを作成するときは、次の設定を使用します。
1. `provider URL` を GitLab インスタンスに設定します。例えば、**gitlab.example.com** です。
1. `audience` または `aud` を **sts.amazonaws.com** に設定します。
1.
**IAM ポリシーとロールを作成する**
IAM ロールとポリシーを作成する必要があります。このロールは [AWS Security Token Service (STS)](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) を使用する GitLab によって引き受けられます。詳細については、「[カスタム信頼ポリシーを使用してロールを作成する](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-custom.html)」を参照してください。
1. IAM コンソールで、IAM ロールを作成するときに次の設定を使用します。
+ `Trusted entity type` を **Web identity** に設定します。
+ `Group` を **your GitLab group** に設定します。
+ ステップ 2 で使用したものと同じプロバイダー URL ([GitLab インスタンス](#step2-oidc-provider)) に `Identity provider` を設定します。
+ ステップ 2 で使用したものと同じ[対象者](#step2-oidc-audience)に `Audience` を設定します。
1. 次に示すのは、GitLab がロールを引き受けることを許可する信頼ポリシーの例です。信頼ポリシーには AWS アカウント、、GitLab URL、および[プロジェクトパス](https://docs.gitlab.com/user/project/)がリストされている必要があります。
****
```
{
"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*"
]
}
}
}
]
}
```
1. また、GitLab に AWS Secrets Managerへのアクセスを許可する IAM ポリシーを作成する必要があります。このポリシーを信頼ポリシーに追加できます。詳細については、「[IAM ポリシーを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)」を参照してください。
****
```
{
"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 設定ファイル](https://docs.gitlab.com/ci/yaml/yaml_optimization/)を以下の情報で更新する必要があります。
+ STS に設定されたトークンの対象者。
+ Secrets Manager のシークレット ID。
+ GitLab パイプラインでジョブを実行するときに GitLab Runner が引き受ける IAM ロール。
+ シークレットが保存され AWS リージョン ている 。
GitLab は Secrets Manager からシークレットを取得し、その値を一時ファイルに保存します。このファイルへのパスは、[ファイルタイプ CI/CD 変数](https://docs.gitlab.com/ci/variables/#use-file-type-cicd-variables)と同様に 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 統合のドキュメント](https://docs.gitlab.com/ci/secrets/aws_secrets_manager/)」を参照してください。
必要に応じて、GitLab で OIDC 設定をテストできます。詳細については、「[OIDC 設定のテストに関する GitLab のドキュメント](https://docs.gitlab.com/ci/cloud_services/aws/#test-the-oidc-configuration)」を参照してください。
## トラブルシューティング
以下は、Secrets Manager を GitLab と統合するときに発生する可能性がある一般的な問題のトラブルシューティングに役立ちます。
### GitLab Pipeline の問題
GitLab パイプラインの問題が発生した場合は、以下を確認してください。
+ YAML ファイルが適切にフォーマットされている。詳細については、「[GitLab のドキュメント](https://docs.gitlab.com/ee/ci/yaml/)」を参照してください。
+ GitLab パイプラインは正しいロールを引き受けており、適切なアクセス許可と正しい AWS Secrets Manager シークレットへのアクセスを持っています。
### その他のリソース
以下のリソースは、GitLab と AWS Secrets Managerに関する問題のトラブルシューティングに役立ちます。
+ [GitLab OIDC のトラブルシューティング](https://docs.gitlab.com/ci/cloud_services/aws/#troubleshooting)
+ [GitLab CI/CD パイプラインのデバッグ](https://docs.gitlab.com/ee/ci/troubleshooting.html)
+ [トラブルシューティング](ascp-eks-installation.md#troubleshooting)