GitLab 차트 사용 시 AWS에 대한 IAM 역할

차트에서 외부 객체 저장에 대한 기본 구성은 액세스 및 시크릿 키를 사용합니다. 또한 kube2iam, kiam, 또는 IRSA와 함께 IAM 역할을 사용할 수도 있습니다.

IAM 역할

IAM 역할은 S3 버킷에 대한 읽기, 쓰기 및 목록 권한이 필요합니다. 버킷 당 역할을 선택하거나 결합할 수 있습니다.

차트 구성

IAM 역할은 아래의 주석을 추가하고 비밀을 변경하여 지정할 수 있습니다:

레지스트리

IAM 역할은 주석 키를 통해 지정할 수 있습니다:

--set registry.annotations."iam\.amazonaws\.com/role"=<role 이름>

registry-storage.yaml 시크릿을 생성할 때, 액세스 및 시크릿 키는 생략합니다:

s3:
  bucket: gitlab-registry
  v4auth: true
  region: us-east-1

참고: 키 쌍을 제공하는 경우 IAM 역할은 무시됩니다. 자세한 내용은 AWS 문서를 참조하세요.

LFS, Artifacts, Uploads, Packages

LFS, artifacts, uploads, 및 packages에 대해 IAM 역할은 webservicesidekiq 구성의 주석 키를 통해 지정할 수 있습니다:

--set gitlab.sidekiq.annotations."iam\.amazonaws\.com/role"=<role 이름>
--set gitlab.webservice.annotations."iam\.amazonaws\.com/role"=<role 이름>

object-storage.yaml 시크릿을 생성할 때, 액세스 및 시크릿 키는 생략합니다. GitLab Rails 코드베이스에서는 S3 저장소에 대해 Fog를 사용하므로, Fog가 역할을 사용하도록하려면 use_iam_profile 키를 추가해야 합니다:

provider: AWS
use_iam_profile: true
region: us-east-1

참고: 이 구성에서 endpoint를 포함하지 마십시오. IRSA는 전문화된 엔드포인트를 사용하는 STS 토큰을 사용합니다. endpoint가 제공되면 AWS 클라이언트는 이 엔드포인트로 AssumeRoleWithWebIdentity 메시지를 보내려고 시도하고 실패합니다.

백업

Toolbox 구성을 통해 주석을 설정하여 S3로 백업을 업로드할 수 있습니다:

--set gitlab.toolbox.annotations."iam\.amazonaws\.com/role"=<role 이름>

s3cmd.config 시크릿을 생성할 때, 액세스 및 시크릿 키는 생략합니다:

[default]
bucket_location = us-east-1

서비스 계정용 IAM 역할 사용

GitLab이 AWS EKS 클러스터(버전 1.14 이상)에서 실행 중인 경우, 액세스 토큰을 생성하거나 저장할 필요없이 S3 객체 저장소에 인증하기 위해 AWS IAM 역할을 사용할 수 있습니다. EKS 클러스터에서 IAM 역할을 사용하는 자세한 내용은 Introducing fine-grained IAM roles for service accounts 문서에서 찾을 수 있습니다.

이 Helm 차트에서 역할에 대한 적절한 IRSA 주석을 ServiceAccounts에 적용하는 방법은 다음 두 가지 중 하나로 가능합니다:

  1. 상기 AWS 문서에 설명된 대로 미리 생성된 ServiceAccounts. 이를 통해 ServiceAccount 및 연결된 OIDC 프로바이더의 적절한 주석을 보장합니다.
  2. 주석이 정의된 차트 생성 ServiceAccounts. 우리는 ServiceAccounts에 대한 주석을 전역적으로 또는 차트별로 구성할 수 있습니다.

AWS EKS 클러스터에서 ServiceAccounts에 대한 IAM 역할을 사용하려면, 특정 주석은 eks.amazonaws.com/role-arn: arn:aws:iam::<ACCOUNT_ID>:role/<IAM_ROLE_NAME> 여야 합니다.

AWS EKS 클러스터에서 실행 중인 GitLab의 서비스 계정용 IAM 역할을 사용하려면, IAM roles for service accounts의 지침에 따르세요.

경고: 백업 설명에 명시된대로 backup-utility를 사용하면 백업 파일을 올바르게 S3 버킷에 복사하지 못합니다. backup-utility는 백업 파일의 복사를 수행하기 위해 s3cmd를 사용하며 OIDC 인증을 지원하지 않는 알려진 문제가 있습니다. 이 문제는 2.2.0 릴리즈에서 해결되었으며, GitLab 14.4에 병합되었습니다.

GitLab 14.4 이전에서 백업 수행하는 방법

버전 14.4 이전에 있는 경우에는 작업런너 팟에서 다음 명령을 실행하여 최신 버전의 s3cmd를 사이드로드한 후에 backup-utility를 평소처럼 실행할 수 있습니다.

pip install --upgrade s3cmd && export PATH="$(python3 -m site --user-base)/bin:${PATH}"

사전에 생성된 서비스 계정 사용

GitLab 차트를 배포할 때 다음 옵션을 설정합니다. ServiceAccount가 활성화되어 있지만 생성되지는 않은 것에 유의해야 합니다.

global:
  serviceAccount:
    enabled: true
    create: false
    name: <SERVICE ACCT NAME>

더 세밀한 ServiceAccounts 제어도 가능합니다:

registry:
  serviceAccount:
    create: false
    name: gitlab-registry
gitlab:
  webservice:
    serviceAccount:
      create: false
      name: gitlab-webservice
  sidekiq:
    serviceAccount:
      create: false
      name: gitlab-sidekiq
  toolbox:
    serviceAccount:
      create: false
      name: gitlab-toolbox

차트 소유의 서비스 계정 사용

eks.amazonaws.com/role-arn 주석은 global.serviceAccount.annotations를 구성함으로써 GitLab 소유 차트에 의해 생성된 모든 ServiceAccounts에 적용될 수 있습니다.

global:
  serviceAccount:
    annotations:
      eks.amazonaws.com/role-arn: arn:aws:iam::xxxxxxxxxxxx:role/name

주석은 각 ServiceAccount에 개별적으로 추가될 수도 있지만, 각 차트에 해당하는 일치하는 정의를 추가해야 합니다. 이는 동일한 역할 또는 개별 역할이 될 수 있습니다.

registry:
  serviceAccount:
    annotations:
      eks.amazonaws.com/role-arn: arn:aws:iam::xxxxxxxxxxxx:role/gitlab-registry
gitlab:
  webservice:
    serviceAccount:
      annotations:
        eks.amazonaws.com/role-arn: arn:aws:iam::xxxxxxxxxxxx:role/gitlab
  sidekiq:
    serviceAccount:
      annotations:
        eks.amazonaws.com/role-arn: arn:aws:iam::xxxxxxxxxxxx:role/gitlab
  toolbox:
    serviceAccount:
      annotations:
        eks.amazonaws.com/role-arn: arn:aws:iam::xxxxxxxxxxxx:role/gitlab-toolbox

문제 해결

IAM 역할이 올바르게 설정되었고 GitLab이 IAM 역할을 사용하여 S3에 액세스하는지 테스트할 수 있습니다. toolbox 팟에 로그인하여 awscli를 사용하여 AWS API와 통신할 수 있는지 확인할 수 있습니다 (<namespace>은 GitLab이 설치된 네임스페이스로 교체).

kubectl exec -ti $(kubectl get pod -n <namespace> -lapp=toolbox -o jsonpath='{.items[0].metadata.name}') -n <namespace> -- bash

awscli 패키지가 설치된 상태에서 AWS API와 통신할 수 있는지 확인합니다:

aws sts get-caller-identity

AWS API에 정상적으로 연결된 경우 일시적 사용자 ID, 계정 번호 및 IAM ARN(이는 S3에 액세스하는 데 사용되는 IAM ARN은 아닙니다)이 표시됩니다. 연결에 실패한 경우 toolbox 팟이 AWS API와 통신할 수 없는 이유를 확인하기 위해 더 많은 문제 해결이 필요합니다.

AWS API에 연결하는 것이 성공하면 다음 명령을 사용하여 생성된 IAM 역할을 가정하고 S3에 액세스할 수 있는 지 확인할 수 있습니다. 환경변수 AWS_ROLE_ARNAWS_WEB_IDENTITY_TOKEN_FILE은 팟에 IAM 역할 주석이 추가되어 환경 안에 정의되어 있으므로 정의할 필요가 없습니다:

aws sts assume-role-with-web-identity --role-arn $AWS_ROLE_ARN  --role-session-name gitlab --web-identity-token file://$AWS_WEB_IDENTITY_TOKEN_FILE

IAM 역할을 가정할 수 없는 경우 다음과 유사한 오류 메시지가 표시됩니다:

An error occurred (AccessDenied) when calling the AssumeRoleWithWebIdentity operation: Not authorized to perform sts:AssumeRoleWithWebIdentity

그렇지 않으면 STS 자격 증명 및 IAM 역할 정보가 표시됩니다.

WebIdentityErr: failed to retrieve credentials

로그에 이 오류가 표시된다면, object-storage.yaml 시크릿에서 endpoint가 구성된 것으로 나타납니다. 이 설정을 제거하고 webservicesidekiq 팟을 다시 시작하십시오.