クラスタ証明書によるアクセス制御（RBACまたはABAC）（非推奨）

GitLabでクラスタを作成する際に、以下のいずれかを作成するかどうかを確認するメッセージが表示されます:

• ロールベースのアクセス制御（RBAC）クラスタ。これはGitLabのデフォルトであり、推奨されるオプションです。
• 属性ベースのアクセス制御（ABAC）クラスタ。

GitLabがクラスタを作成すると、gitlabサービスアカウント（cluster-admin権限を持つ）がdefaultネームスペースに作成され、新しく作成されたクラスタを管理します。

Helmは、インストールされている各アプリケーションに対して、追加のサービスアカウントやその他のリソースも作成します。詳細については、アプリケーションごとのHelmチャートのドキュメントを参照してください。

既存のKubernetesクラスタを追加する場合は、アカウントのトークンにクラスタの管理者権限があることを確認してください。

GitLabによって作成されるリソースは、クラスタのタイプによって異なります。

重要な注意点

アクセス制御に関する以下の点に注意してください:

• 環境固有のリソースは、クラスタがGitLabによって管理されている場合にのみ作成されます。
• クラスタがGitLab 12.2より前に作成された場合、すべてのプロジェクト環境に対して単一のネームスペースを使用します。

RBACクラスタのリソース

GitLabは、RBACクラスタに対して以下のリソースを作成します。

ABACクラスタのリソース

GitLabは、ABACクラスタに対して以下のリソースを作成します。

Runnerのセキュリティ

Runnerは、特権モードがデフォルトで有効になっており、特別なコマンドを実行したり、DockerでDockerを実行したりできます。この機能は、一部のAuto DevOpsジョブを実行するために必要です。これは、コンテナが特権モードで実行されていることを意味し、したがって、いくつかの重要な詳細に注意する必要があります。

特権フラグは、実行中のコンテナにすべての機能を提供し、ホストができるほとんどすべてのことを実行できます。docker run操作を任意のイメージに対して実行することに伴う固有のセキュリティリスクに注意してください。これらは事実上、rootアクセス権を持っています。

特権モードでRunnerを使用したくない場合は、次のいずれかを行います:

• GitLab.comでインスタンスRunnerを使用します。これらには、このセキュリティ上の問題はありません。
• docker+machineを使用する独自のRunnerをセットアップします。