• IAM 역할
• 차트 구성
  • 레지스트리
  • LFS, 아티팩트, 업로드, 패키지
  • 백업
  • 서비스 계정에 대한 IAM 역할 사용
    • 미리 생성된 서비스 계정 사용
    • 차트 소유 서비스 계정 사용
• 문제 해결
• WebIdentityErr: 자격 증명 검색 실패

GitLab 차트를 사용할 때 AWS의 IAM 역할

차트의 기본 구성은 액세스 키와 비밀 키를 사용하는 외부 객체 저장소입니다.

IAM 역할을 kube2iam, kiam 또는 IRSA와 조합하여 사용할 수도 있습니다.

IAM 역할

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

차트 구성

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

레지스트리

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

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

registry-storage.yaml 비밀을 생성할 때 액세스 및 비밀 키를 생략하십시오:

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

참고: 키 쌍을 제공하면 IAM 역할이 무시됩니다. 자세한 내용은 AWS 문서를 참조하십시오.

LFS, 아티팩트, 업로드, 패키지

LFS, 아티팩트, 업로드 및 패키지에 대해 IAM 역할은 webservice 및 sidekiq 구성에서 주석 키를 통해 지정할 수 있습니다:

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

object-storage.yaml 비밀에 대해서는 액세스 및 비밀 키를 생략하십시오. GitLab Rails 코드베이스는 S3 저장소에 Fog를 사용하므로, use_iam_profile 키를 추가해야 Fog가 역할을 사용합니다:

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

참고: 이 구성에서 endpoint를 포함하지 마십시오.

IRSA는 STS 토큰을 사용하며, 이는 특수화된 엔드포인트를 사용합니다. endpoint가 제공되면 AWS 클라이언트는 이 엔드포인트에 AssumeRoleWithWebIdentity 메시지를 보내려고 시도하고 실패합니다.

백업

툴박스 구성에서는 S3에 백업을 업로드하기 위해 주석을 설정할 수 있습니다:

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

s3cmd.config 비밀은 액세스 및 비밀 키 없이 생성되어야 합니다:

[default]
bucket_location = us-east-1

서비스 계정에 대한 IAM 역할 사용

GitLab이 AWS EKS 클러스터(버전 1.14 이상)에서 실행되고 있다면, 액세스 토큰을 생성하거나 저장할 필요 없이 AWS IAM 역할을 사용하여 S3 객체 저장소에 인증할 수 있습니다. EKS 클러스터에서 IAM 역할을 사용하는 것에 대한 더 많은 정보는 AWS의 서비스 계정을 위한 세밀한 IAM 역할 소개 문서를 참조하십시오.

역할에 대한 적절한 IRSA 주석을 이 Helm 차트의 ServiceAccounts에 두 가지 방법 중 하나로 적용할 수 있습니다:

1. 위의 AWS 문서에서 설명한 대로 미리 생성된 ServiceAccounts 이 방법은 ServiceAccount 및 연결된 OIDC 제공자에 대한 적절한 주석을 보장합니다.

2. 주석이 정의된 차트 생성 ServiceAccounts 우리는 ServiceAccounts에 대한 주석을 전역적으로 및 차트별로 구성할 수 있도록 허용합니다.

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

GitLab이 AWS EKS 클러스터에서 실행될 때 ServiceAccounts에 대한 IAM 역할을 활성화하려면 서비스 계정을 위한 IAM 역할의 지침을 따르십시오.

미리 생성된 서비스 계정 사용

GitLab 차트가 배포될 때 다음 옵션을 설정하십시오. ServiceAccount가 활성화되었지만 생성되지 않았다는 점은 중요합니다.

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

세분화된 ServiceAccounts 제어도 가능합니다:

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

IAM 역할의 신뢰 정책이 이 Kubernetes 서비스 계정을 신뢰하도록 구성되었는지 확인하십시오.

차트 소유 서비스 계정 사용

eks.amazonaws.com/role-arn 주석은 GitLab 소유 차트에 의해 생성된 모든 ServiceAccounts에 적용될 수 있으며, global.serviceAccount.annotations를 설정하여 구성합니다.

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

주석은 서비스 계정별로 추가할 수 있지만 각 차트에 대한 일치하는 정의를 추가해야 합니다. 이들은 같은 역할이거나 개별 역할이 될 수 있습니다.

registry:
  serviceAccount:
    annotations:
      eks.amazonaws.com/role-arn: arn:aws:iam::xxxxxxxxxxxx:role/gitlab-registry
gitlab:
  migrations:
    serviceAccount:
      annotations:
        eks.amazonaws.com/role-arn: arn:aws:iam::xxxxxxxxxxxx:role/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를 사용하세요(여기서 <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 접근을 위한 STS 토큰을 검색할 수 있습니다. IAM 역할 주석이 포드에 추가되면 AWS_ROLE_ARN과 AWS_WEB_IDENTITY_TOKEN_FILE 변수가 환경에 정의되며, 별도로 정의할 필요는 없습니다:

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: 자격 증명 검색 실패

로그에서 이 오류가 나타나면, 이는 endpoint가 object-storage.yaml 비밀에 구성되었음을 나타냅니다. 이 설정을 제거하고 webservice 및 sidekiq 팟을 재시작하세요.