• IAM 역할
• 차트 구성
  • 레지스트리
  • LFS, Artifacts, Uploads, Packages
  • 백업
  • 서비스 계정용 IAM 역할 사용
    • 미리 생성된 서비스 계정 사용
    • 차트 소유의 서비스 계정 사용
• 문제 해결
• WebIdentityErr: 자격 증명 검색에 실패함

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

차트의 외부 객체 리포지터리의 기본 구성은 액세스 및 시크릿 키를 사용합니다. 또한 kube2iam, kiam, 또는 IRSA와 결합하여 IAM 역할을 사용할 수도 있습니다.

IAM 역할

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

차트 구성

다음과 같이 주석을 추가하고 시크릿을 변경하여 IAM 역할을 지정할 수 있습니다.

레지스트리

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

--set registry.annotations."iam\.amazonaws\.com/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 역할을 주석 키를 통해 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를 사용하므로, 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"=<역할 이름>

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

[default]
bucket_location = us-east-1

서비스 계정용 IAM 역할 사용

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

이 Helm 차트 전체에서 ServiceAccounts에 대한 적절한 IRSA 주석은 다음 두 가지 방법 중 하나로 적용할 수 있습니다:

1. 위의 AWS 문서에 설명된 대로 미리 생성된 ServiceAccounts. 이를 통해 ServiceAccount와 연결된 올바른 주석이 보장됩니다.
2. 정의된 주석이 있는 차트 생성 ServiceAccounts. 우리는 ServiceAccounts에 대한 주석을 글로벌 설정과 차트별로 구성할 수 있습니다.

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

AWS EKS 클러스터에서 GitLab을 실행하는 경우, IAM roles for service accounts의 지침에 따르세요.

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

GitLab 차트를 배포할 때 다음 옵션을 설정합니다. ServiceAccount가 활성화되지만 생성되지는 않습니다.

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

정교한 ServiceAccount 제어도 가능합니다:

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

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

global.serviceAccount.annotations를 구성하여 GitLab 소유 차트에 의해 생성된 모든 ServiceAccounts에 eks.amazonaws.com/role-arn 주석을 추가할 수 있습니다.

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를 사용합니다 (여기서 <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

정상적인 응답으로 임시 사용자 ID, 계정 번호 및 IAM ARN(이는 S3에 액세스하는 데 사용되는 IAM ARN이 아닐 것입니다)이 표시됩니다. 연결에 실패하면 toolbox 파드가 AWS API와 통신할 수 없는 이유를 확인해야 합니다.

AWS API에 연결하는 것이 성공하면 다음 명령은 생성된 IAM 역할을 가정하고 S3에 액세스할 수 있는 STS 토큰을 검색할 수 있는지 확인합니다. AWS_ROLE_ARN 및 AWS_WEB_IDENTITY_TOKEN_FILE 변수는 환경에 정의되어 있고 Pod에 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: 자격 증명 검색에 실패함

로그에서 이 오류를 확인하면, endpoint가 귀하의 object-storage.yaml 비밀에 구성되었다는 것을 시사합니다. 이 설정을 제거하고 webservice 및 sidekiq 파드를 다시 시작하십시오.