기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# GitLab AWS Secrets Manager 에서 사용
<a name="integrating_gitlab"></a>

AWS Secrets Manager 는 GitLab과 통합됩니다. Secrets Manager 보안 암호를 활용하여 GitLab 자격 증명을 보호할 수 있으며, 더 이상 GitLab에 하드코딩할 필요가 없습니다. 대신, [GitLab Runner](https://docs.gitlab.com/runner/)는 GitLab CI/CD 파이프라인에서 애플리케이션이 작업을 실행할 때 Secrets Manager에서 이러한 보안 암호를 가져옵니다.

이 통합을 사용하려면 [IAM 및 IAM 역할에 OpenID Connect(OIDC) 자격 증명 공급자](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/)를 참조하세요.

## 고려 사항
<a name="gitlab-integration-considerations"></a>

비공개 GitLab 인스턴스를 사용하는 경우, 이 Secrets Manager 통합 기능을 사용할 수 없습니다. 이 경우 [비공개 인스턴스에 대한 GitLab 문서](https://docs.gitlab.com/ci/cloud_services/aws/#configure-a-non-public-gitlab-instance)를 참조하세요.

## 사전 조건
<a name="gitlab-integration-prerequisites"></a>

Secrets Manager를 GitLab과 통합하려면 다음 사전 준비 단계를 완료해야 합니다.

1. 

**AWS Secrets Manager 보안 암호 생성**

   GitLab 작업에서 가져올 Secrets Manager 보안 암호를 생성해야 합니다. 이렇게 하면 자격 증명을 GitLab 설정 파일에 하드코딩할 필요가 없습니다. [GitLab 파이프라인](#configure-gitlab-pipeline)을 구성할 때 Secrets Manager 보안 암호 ID가 필요합니다. 자세한 내용은 [AWS Secrets Manager 보안 암호 생성](create_secret.md) 섹션을 참조하세요.

1. 

**IAM 콘솔에서 GitLab을 OIDC 공급자로 설정**

   이 단계에서는 IAM 콘솔에서 GitLab을 OIDC 공급자로 등록합니다. 자세한 내용은 [OpenID Connect(OIDC) 자격 증명 공급자 생성](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_providers_create_oidc.html) 및 [GitLab 설명서](https://docs.gitlab.com/ci/cloud_services/aws/)를 참조하세요.

   OIDC 공급자를 생성할 때는 다음 구성을 사용합니다.

   1. <a name="step2-oidc-provider"></a>`provider URL`을 GitLab 인스턴스로 설정합니다. 예를 들어 **gitlab.example.com**입니다.

   1. <a name="step2-oidc-audience"></a>`audience` 또는 `aud`를 **sts.amazonaws.com**으로 설정합니다.

1. 

**IAM 역할 및 정책 생성**

   IAM 정책 및 역할을 생성해야 합니다. 이 역할은 GitLab이 [AWS Security Token Service (STS)](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html)를 통해 담당합니다. 자세한 내용은 [사용자 지정 신뢰 정책을 사용하여 역할 생성](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**로 설정합니다.
      + `Identity provider`를 2단계에서 사용한 것과 동일한 공급자 URL([GitLab 인스턴스](#step2-oidc-provider))로 설정합니다.
      + `Audience`를 2단계에서 사용한 것과 동일한 [대상](#step2-oidc-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 과 통합
<a name="integrating-aws-secrets-manager-gitlab"></a>

위의 사전 단계를 완료한 후, GitLab을 구성하여 Secrets Manager를 통해 자격 증명을 보호할 수 있습니다.

### Secrets Manager를 사용하기 위해 GitLab 파이프라인 구성
<a name="configure-gitlab-pipeline"></a>

[GitLab CI/CD 구성 파일](https://docs.gitlab.com/ci/yaml/yaml_optimization/)을 다음 정보로 업데이트해야 합니다.
+ STS로 설정된 토큰의 대상.
+ Secrets Manager 보안 암호.
+ 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"
```

자세한 내용은 [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)를 참조하세요.

## 문제 해결
<a name="troubleshooting-integration"></a>

다음은 Secrets Manager를 GitLab과 통합할 때 발생할 수 있는 일반적인 문제를 해결하는 데 도움이 될 수 있습니다.

### GitLab 파이프라인 관련 문제
<a name="gitlab-pipeline-issues"></a>

GitLab 파이프라인에서 문제가 발생한 경우, 다음 사항을 확인하세요.
+ YAML 파일 형식이 올바른지 확인합니다. 자세한 내용은 [GitLab 설명서](https://docs.gitlab.com/ee/ci/yaml/)를 참조하세요.
+ GitLab 파이프라인이 올바른 역할을 수임하고, 적절한 권한을 가지며, 올바른 AWS Secrets Manager 보안 암호에 액세스합니다.

### 추가 리소스
<a name="additional-resources"></a>

다음 리소스는 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)