GitLabチャートを使用する場合のAWSのIAMロール

Chartの外部オブジェクトストレージのデフォルト設定では、アクセスキーとシークレットキーを使います。IAM ロールをkube2iam,kiam,IRSAと組み合わせて使用することも可能です。

IAM ロール

IAMロールはS3バケットの読み取り、書き込み、リスト権限を必要とします。バケットごとにロールを持つか、それらを組み合わせるかを選択できます。

Chartの設定

IAMロールは、以下のようにアノテーションを追加してシークレットを変更することで指定できます：

レジストリ

IAM ロールは annotations キーで指定します：

--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、アーティファクト、アップロード、パッケージについては、webservice およびsidekiq 設定の注釈キーで IAM ロールを指定できます：

--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
note
endpoint この設定 endpointには含めないでください。endpoint IRSA は、専用のエンドポイントを使う STS トークンを利用します。 endpointこれが提供さendpoint れると endpoint、AWS クライアントはこのエンドポイントにAssumeRoleWithWebIdentity メッセージを送信しようとして失敗します。

バックアップ

Toolboxの設定では、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のIntroducing fine-grained IAM roles for serviceaccountsのドキュメントを参照してください。

このHelmチャート全体を通して、ロールに対する適切なIRSAアノテーションは、2つの方法のいずれかでServiceAccountsに適用できます：

  1. 上記のAWSドキュメントに記載されているように事前に作成されたServiceAccount。これにより、ServiceAccountとリンクされたOIDCプロバイダに適切なアノテーションが付与されます。
  2. アノテーションが定義されたChart生成ServiceAccounts。グローバルおよびChart単位でServiceAccountにアノテーションを設定することができます。

EKSクラスターでServiceAccountsにIAMロールを使用するには、特定のアノテーションをeks.amazonaws.com/role-arn: arn:aws:iam::<ACCOUNT_ID>:role/<IAM_ROLE_NAME> 。

AWS EKSクラスターで稼働しているGitLabでServiceAccount用のIAMロールを有効にするには、サービスアカウント用のIAMロールに関する説明に従ってください。

caution
backup-utility バックアップのドキュメントで指定されているように backup-utility使用しても、backup-utility バックアップファイルが S3 バケットに正しくコピー backup-utilityされません。バックアップファイルのコピーの実行にs3cmd backup-utility を backup-utility使用しており、OIDC 認証をサポートしていないという既知のイシューがあります。これは GitLab 14.4 にマージされた 2.2.0 リリースで解決されました。

GitLab 14.4以前のバックアップの回避策

14.4より前のバージョンを使っている場合は、task-runnerポッドで以下のコマンドを実行し、最新バージョンの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

Chart所有のサービス・アカウントの使用

global.serviceAccount.annotations を設定することで、GitLab所有のChartが作成した_すべての_ServiceAccountに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

トラブルシューティング

toolbox ポッドにログインしてawscli (<namespace> は GitLab がインストールされているネームスペースに置き換えてください) を使うことで、IAM ロールが正しく設定されているか、GitLab が IAM ロールを使って S3 にアクセスしているかをテストすることができます：

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トークンが取得できることを確認します。AWS_ROLE_ARN とAWS_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 が設定されていることを示唆しています。この設定を削除し、webservice とsidekiq ポッドを再起動します。