GitLab에서 AWS Secrets Manager 사용 - AWS Secrets Manager

GitLab에서 AWS Secrets Manager 사용

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

이 통합 기능을 사용하려면 AWS Identity and Access Management(IAM)에서 OpenID Connect(OIDC) ID 공급자와 IAM 역할을 생성해야 합니다. 이를 통해 GitLab Runner가 Secrets Manager 보안 암호에 액세스할 수 있습니다. GitLab CI/CD 및 OIDC에 대한 자세한 내용은 GitLab 설명서를 참조하세요.

고려 사항

비공개 GitLab 인스턴스를 사용하는 경우, 이 Secrets Manager 통합 기능을 사용할 수 없습니다. 이 경우 비공개 인스턴스에 대한 GitLab 문서를 참조하세요.

사전 조건

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

  1. AWS Secrets Manager 보안 암호 생성

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

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

    이 단계에서는 IAM 콘솔에서 GitLab을 OIDC 공급자로 등록합니다. 자세한 내용은 OpenID Connect(OIDC) 자격 증명 공급자 생성GitLab 설명서를 참조하세요.

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

    1. provider URL을 GitLab 인스턴스로 설정합니다. 예를 들어 gitlab.example.com입니다.

    2. audience 또는 audsts.amazonaws.com으로 설정합니다.

  3. IAM 역할 및 정책 생성

    IAM 정책 및 역할을 생성해야 합니다. 이 역할은 GitLab이 AWS Security Token Service(STS)를 통해 담당합니다. 자세한 내용은 사용자 지정 신뢰 정책을 사용하여 역할 생성을 참조하세요.

    1. IAM 콘솔에서 IAM 역할을 생성할 때 다음 설정을 사용합니다.

      • Trusted entity typeWeb identity으로 설정합니다.

      • Groupyour GitLab group로 설정합니다.

      • Identity provider를 2단계에서 사용한 것과 동일한 공급자 URL(GitLab 인스턴스)로 설정합니다.

      • Audience를 2단계에서 사용한 것과 동일한 대상으로 설정합니다.

    2. 다음은 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*" ] } } } ] }
    3. 또한 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 통합

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

Secrets Manager를 사용하기 위해 GitLab 파이프라인 구성

GitLab CI/CD 구성 파일을 다음 정보로 업데이트해야 합니다.

  • STS로 설정된 토큰의 대상.

  • Secrets Manager 보안 암호.

  • 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"

자세한 내용은 Secrets Manager 통합 설명서를 참조하세요.

원할 경우 GitLab에서 OIDC 구성을 테스트할 수도 있습니다. 자세한 내용은 OIDC 구성 테스트에 대한 GitLab 설명서를 참조하세요.

문제 해결

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

GitLab 파이프라인 관련 문제

GitLab 파이프라인에서 문제가 발생한 경우, 다음 사항을 확인하세요.

  • YAML 파일 형식이 올바른지 확인합니다. 자세한 내용은 GitLab 설명서를 참조하세요.

  • GitLab 파이프라인이 올바른 역할을 담당하고, 적절한 권한을 가지며, 올바른 AWS Secrets Manager 보안 암호에 대한 액세스 권한을 가지고 있는지 확인합니다.

추가 리소스

다음 리소스는 GitLab 및 AWS Secrets Manager 관련 문제를 해결하는 데 도움이 될 수 있습니다.