クラスター証明書によるアクセス制御(RBACまたはABAC)(非推奨)
GitLabでクラスターを作成するとき、どちらを作成するか尋ねられます:
- ARole-based access control(RBAC)クラスター。これはGitLabのデフォルトであり、推奨されるオプションです。
- Attribute-based accesscontrol(ABAC)クラスター。
GitLab がクラスターを作成すると、default
名前空間にcluster-admin
権限を持つgitlab
サービスアカウントが作成され、新しく作成されたクラスターを管理します。
Helmはインストールしたアプリケーションごとに追加のサービスアカウントやその他のリソースも作成します。詳細は各アプリケーションのHelmチャートのドキュメントを参照してください。
既存のKubernetesクラスターを追加する場合は、アカウントのトークンがクラスターの管理者権限を持っていることを確認してください。
GitLabが作成するリソースはクラスターの種類によって異なります。
重要な注意事項
アクセス制御について、以下の点にご注意ください:
- 環境固有のリソースは、クラスターがGitLabによって管理されている場合にのみ作成されます。
- クラスターがGitLab 12.2より前に作成された場合は、すべてのプロジェクト環境に対して単一の名前空間を使用します。
RBAC クラスターリソース
GitLabはRBACクラスタ用に以下のリソースを作成します。
名前 | 種類 | 詳細 | 作成時期 |
---|---|---|---|
gitlab | ServiceAccount |
default 名前空間 | 新しいクラスターの作成 |
gitlab-admin | ClusterRoleBinding |
cluster-admin ロール | 新しいクラスターの作成 |
gitlab-token | Secret |
gitlab ServiceAccount 用トークン | 新しいクラスターの作成 |
環境ネームスペース | Namespace | 環境固有のリソースをすべて含みます。 | クラスターへのデプロイ |
環境ネームスペース | ServiceAccount | 環境の名前空間を使用します。 | クラスターへのデプロイ |
環境ネームスペース | Secret | 環境のトークン ServiceAccount | クラスターへのデプロイ |
環境ネームスペース | RoleBinding |
admin ロール | クラスターへのデプロイ |
GitLab 13.6で環境名前空間RoleBinding
が更新され、admin
ロールになりました。以前はedit
ロールが使われていました。
ABACクラスターのリソース
GitLabはABACクラスター用に以下のリソースを作成します。
名前 | 種類 | 詳細 | 作成時期 |
---|---|---|---|
gitlab | ServiceAccount |
default 名前空間 | 新しいクラスターの作成 |
gitlab-token | Secret |
gitlab ServiceAccount 用トークン | 新しいクラスターの作成 |
環境ネームスペース | Namespace | 環境固有のリソースをすべて含みます。 | クラスターへのデプロイ |
環境ネームスペース | ServiceAccount | 環境の名前空間を使用します。 | クラスターへのデプロイ |
環境ネームスペース | Secret | 環境のトークン ServiceAccount | クラスターへのデプロイ |
ランナーのセキュリティ
ランナーはデフォルトで特権モードが有効になっており、特別なコマンドを実行したり、Docker内でDockerを実行したりすることができます。この機能はAuto DevOpsジョブの一部を実行するために必要です。これはコンテナが特権モードで実行されていることを意味するため、いくつかの重要な点に注意する必要があります。
特権フラグは実行中のコンテナにすべての機能を与え、コンテナはホストができることのほとんどすべてを行うことができます。任意のイメージに対してdocker run
のオペレーションを実行すると、事実上 root アクセスが可能になるため、内部セキュリティリスクに注意してください。
特権モードで Runner を使いたくない場合は、次のようにします:
- GitLab.comの共有ランナーを使いましょう。このセキュリティ問題はありません。
-
docker+machine
を使う独自の Runner をセットアップしましょう。