GitLabチャートのRBAC設定

Kubernetes 1.7までは、クラスター内の権限はありませんでした。1.7のローンチにより、クラスター内でどのサービスがアクションを実行できるかを決定するロールベースのアクセス制御システム（RBAC）が導入されました。

RBACはGitLabのいくつかの異なる側面に影響を与えます：

  • Helmを使ったGitLabのインストール
  • Prometheus モニタリング
  • GitLab Runner
  • クラスター内のPostgreSQLデータベース（RBACが有効な場合）
  • 証明書マネージャ

RBACが有効になっていることの確認

現在のクラスターのロールをリストアップしてみて、失敗したらRBAC 。

このコマンドは、RBAC が無効な場合はfalse 、そうでない場合はtrue を出力します。

kubectl get clusterroles > /dev/null 2>&1 && echo true || echo false

サービスアカウント

GitLab Chartは特定のタスクを実行するためにServiceアカウントを使用します。これらのアカウントと関連するロールはChartによって作成・管理されます。

サービスアカウントは以下の表で説明されています。それぞれのサービスアカウントについて、表は次のようになっています：

  • 名前の接尾辞（接頭辞はリリース名）。
  • 簡単な説明。例えば、どこで使われているか、何に使われているかなど。
  • 関連するロールと、どのリソースにどのレベルでアクセスできるか。アクセス・レベルは、読み取り専用(R) 、書き込み専用(W)、または読み取り/書き込み(RW)のいずれかです。リソースのグループ名は省略されます。
  • ロールのスコープ。これはクラスター(C) または名前空間(NS)のいずれかです。インスタンスによっては、ロールのスコープはどちらかの値で設定できます（NS/Cで示されます）。
名前接尾辞説明ロールスコープ
gitlab-runnerGitLab Runnerはこのアカウントで実行されます。リソース(RW)NS/C
ingress-nginxNGINX Ingress がサービスのアクセスポイントを制御するために使用します。シークレット、ポッド、エンドポイント、イングレス(R); イベント(W); コンフィグマップ、サービス(RW)NS/C
shared-secrets共有シークレットを作成するジョブはこのアカウントで実行されます。(プリインストール/アップグレードフックで)シークレット(RW)NS
cert-manager証明書マネージャを制御するジョブは、このアカウントで実行されます。発行者、証明書、CertificateRequest、順序(RW)NS/C

GitLab Chartは他のChartもRBACを使っていて、独自のサービスアカウントやロールバインディングを作成していることに依存しています。以下はその概要です：

  • Prometheus monitoringはデフォルトで複数の独自のサービスアカウントを作成します。これらはすべてクラスター・レベルのロールに関連付けられます。詳細はPrometheusのChartドキュメントを参照してください。
  • Certificate managerはデフォルトでサービスアカウントを作成し、クラスター・レベルのネイティブ・リソースとともにカスタム・リソースを管理します。詳細については、cert-managerチャートRBACテンプレートを参照してください。
  • クラスタ内でPostgreSQLデータベースを使用する場合(これがデフォルトです)、サービスアカウントは有効になりません。有効にすることはできますが、PostgreSQLサービスの実行にのみ使用され、特定のロールには関連付けられません。詳細はPostgreSQLのChartを参照してください。