GitLab에서 AWS Secrets Manager 사용
AWS Secrets Manager는 GitLab과 통합됩니다. Secrets Manager 보안 암호를 활용하여 GitLab 자격 증명을 보호할 수 있으며, 더 이상 GitLab에 하드코딩할 필요가 없습니다. 대신, GitLab Runner
이 통합 기능을 사용하려면 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과 통합하려면 다음 사전 준비 단계를 완료해야 합니다.
-
AWS Secrets Manager 보안 암호 생성
GitLab 작업에서 가져올 Secrets Manager 보안 암호를 생성해야 합니다. 이렇게 하면 자격 증명을 GitLab 설정 파일에 하드코딩할 필요가 없습니다. GitLab 파이프라인을 구성할 때 Secrets Manager 보안 암호 ID가 필요합니다. 자세한 내용은 AWS Secrets Manager 보안 암호 생성 섹션을 참조하세요.
-
IAM 콘솔에서 GitLab을 OIDC 공급자로 설정
이 단계에서는 IAM 콘솔에서 GitLab을 OIDC 공급자로 등록합니다. 자세한 내용은 OpenID Connect(OIDC) 자격 증명 공급자 생성 및 GitLab 설명서
를 참조하세요. OIDC 공급자를 생성할 때는 다음 구성을 사용합니다.
-
provider URL을 GitLab 인스턴스로 설정합니다. 예를 들어gitlab.example.com입니다. -
audience또는aud를sts.amazonaws.com으로 설정합니다.
-
-
IAM 역할 및 정책 생성
IAM 정책 및 역할을 생성해야 합니다. 이 역할은 GitLab이 AWS Security Token Service(STS)를 통해 담당합니다. 자세한 내용은 사용자 지정 신뢰 정책을 사용하여 역할 생성을 참조하세요.
-
IAM 콘솔에서 IAM 역할을 생성할 때 다음 설정을 사용합니다.
-
Trusted entity type을Web identity으로 설정합니다. -
Group를your GitLab group로 설정합니다. -
Identity provider를 2단계에서 사용한 것과 동일한 공급자 URL(GitLab 인스턴스)로 설정합니다. -
Audience를 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*" ] } } } ] }
-
또한 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 변수
다음은 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"
자세한 내용은 Secrets Manager 통합 설명서
원할 경우 GitLab에서 OIDC 구성을 테스트할 수도 있습니다. 자세한 내용은 OIDC 구성 테스트에 대한 GitLab 설명서
문제 해결
다음은 Secrets Manager를 GitLab과 통합할 때 발생할 수 있는 일반적인 문제를 해결하는 데 도움이 될 수 있습니다.
GitLab 파이프라인 관련 문제
GitLab 파이프라인에서 문제가 발생한 경우, 다음 사항을 확인하세요.
-
YAML 파일 형식이 올바른지 확인합니다. 자세한 내용은 GitLab 설명서
를 참조하세요. -
GitLab 파이프라인이 올바른 역할을 담당하고, 적절한 권한을 가지며, 올바른 AWS Secrets Manager 보안 암호에 대한 액세스 권한을 가지고 있는지 확인합니다.
추가 리소스
다음 리소스는 GitLab 및 AWS Secrets Manager 관련 문제를 해결하는 데 도움이 될 수 있습니다.