IAMロールとGitLabチャートを使用したAWSの設定

このチャートの外部オブジェクトストレージのデフォルト構成では、アクセストークンとシークレットキーを使用します。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

バックアップ

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のサービスアカウントへのきめ細かいIAMロールの導入ドキュメントに記載されています。

ロールに対する適切なIRSA注釈は、次の2つの方法のいずれかで、このHelm Chart全体のサービスアカウントに適用できます:

1. 上記のAWSドキュメントで説明されているように、事前に作成されたサービスアカウント。これにより、サービスアカウントとリンクされたOIDCプロバイダーに対する適切な注釈が保証されます。
2. 注釈が定義されたチャート生成サービスアカウント。サービスアカウントの注釈の設定は、グローバルベースとチャートごとのベースの両方で許可されています。

EKSクラスタリングのサービスアカウントにIAMロールを使用するには、特定の注釈がeks.amazonaws.com/role-arn: arn:aws:iam::<ACCOUNT_ID>:role/<IAM_ROLE_NAME>である必要があります。

AWS EKSクラスタリングで実行されているGitLabのサービスアカウントに対してIAMロールを有効にするには、サービスアカウントのIAMロールの手順に従ってください。

事前に作成されたサービスアカウントの使用

GitLabチャートのデプロイ時に、次のオプションを設定します。サービスアカウントは有効になっていますが、作成されていないことに注意してください。

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

きめ細かいサービスアカウント制御も利用できます:

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サービスアカウントを信頼するように構成されていることを確認してください。

チャートが所有するサービスアカウントの使用

GitLabが所有するチャートによって作成された_すべて_のサービスアカウントにeks.amazonaws.com/role-arn注釈を適用するには、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 Amazonリソースネーム（これは、S3へのアクセスに使用されるロールのIAM Amazonリソースネームではありません）を示す通常の応答が返されます。接続が失敗した場合、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: failed to retrieve credentials

ログにこのエラーが表示された場合、endpointがobject-storage.yamlシークレットで設定されていることを示唆しています。この設定を削除し、webserviceとsidekiqポッドを再起動します。