ユーザーにKubernetesアクセス権を付与（無料オールベータ）

  • GitLab 16.1 で導入され、environment_settings_to_graphql,kas_user_access,kas_user_access_project,expose_authorized_cluster_agentsというフラグがあります。この機能はベータ版です。
  • 機能フラグenvironment_settings_to_graphql はGitLab 16.2で削除されました。
  • GitLab 16.2で機能フラグkas_user_access,kas_user_access_project,expose_authorized_cluster_agents が削除されました。

組織内のKubernetesクラスターの管理者として、特定のプロジェクトやグループのメンバーにKubernetesアクセスを許可することができます。

アクセスを許可すると、プロジェクトまたはグループのKubernetes用ダッシュボードもアクティビティになります。

セルフマネージドインスタンスの場合は、以下のいずれかを確認してください：

  • GitLab インスタンスとKASを同じドメインでホストしてください。
  • KASをGitLabのサブドメインでホストします。例えば、GitLabはgitlab.com 、KASはkas.gitlab.com 。

Kubernetesアクセスの設定

ユーザーにKubernetesクラスターへのアクセスを許可する場合にアクセスを設定します。

前提条件：

  • Kubernetes用エージェントがKubernetesクラスターにインストールされていること。
  • 開発者ロール以上が必要です。

アクセスを設定するには

  • エージェント設定ファイルで、user_access キーワードを以下のパラメータで定義します：

    • projects:メンバがアクセス権を持つプロジェクトのリスト。
    • groups:メンバーがアクセス権を持つグループのリスト。
    • access_as:必須。プレーンアクセスの場合、値は{ agent: {...} } です。

アクセス設定後、リクエストはエージェントサービスアカウントを使用して API サーバに転送されます。例えば

# .gitlab/agents/my-agent/config.yaml

user_access:
  access_as:
    agent: {}
  projects:
    - id: group-1/project-1
    - id: group-2/project-2
  groups:
    - id: group-2
    - id: group-3/subgroup

ユーザーなりすましによるアクセスの設定

Kubernetesクラスターへのアクセスを許可し、リクエストを認証ユーザー用のインパーソネーションリクエストに変換できます。

前提条件：

  • Kubernetes用エージェントがKubernetesクラスターにインストールされていること。
  • 開発者ロール以上が必要です。

ユーザーなりすましによるアクセスを設定するには、以下の手順に従います：

  • エージェント設定ファイルで、user_access キーワードを以下のパラメータで定義します：

    • projects:メンバがアクセス権を持つプロジェクトのリスト。
    • groups:メンバーがアクセス権を持つグループのリスト。
    • access_as:必須。ユーザーなりすましの場合、値は{ user: {...} } です。

アクセスを設定すると、要求は認証済みユーザーのなりすまし要求に変換されます。

ユーザーなりすましワークフロー

インストールされたagentk は、以下のように指定されたユーザーになりすまします：

  • UserName はgitlab:user:<username>
  • Groups です：
    • gitlab:user:GitLabユーザーからのリクエストに共通です。
    • gitlab:project_role:<project_id>:<role> 各プロジェクト内の各ロールに適用されます。
    • gitlab:group_role:<group_id>:<role> 各認証されたグループの各ロールについて。
  • Extra はリクエストに関する追加情報を運びます：
    • agent.gitlab.com/id:エージェントID。
    • agent.gitlab.com/username:GitLabユーザーのユーザー名。
    • agent.gitlab.com/config_project_id:エージェント設定プロジェクトID。
    • agent.gitlab.com/access_type:personal_access_token,oidc_id_token,session_cookieのいずれか。

設定ファイルのuser_access の下に直接リストされているプロジェクトとグループのみがインポートされます。例えば

# .gitlab/agents/my-agent/config.yaml

user_access:
  access_as:
    user: {}
  projects:
    - id: group-1/project-1 # group_id=1, project_id=1
    - id: group-2/project-2 # group_id=2, project_id=2
  groups:
    - id: group-2 # group_id=2
    - id: group-3/subgroup # group_id=3, group_id=4

この設定では

  • ユーザーがgroup-1 のみのメンバーである場合、Kubernetes RBAC グループgitlab:project_role:1:<role> のみを受け取ります。
  • ユーザーがgroup-2 のメンバーである場合、Kubernetes RBACグループの両方を受け取ります：
    • gitlab:project_role:2:<role>,
    • gitlab:group_role:2:<role>.

RBACの作成者

Impersonatedリクエストでは、Kubernetes内部のリソース権限を識別するために、ClusterRoleBinding またはRoleBinding が必要です。適切な設定についてはRBAC認可を参照してください。

たとえば、awesome-org/deployment プロジェクト（ID: 123）のメンテナーにKubernetesワークロードの読み取りを許可する場合、ClusterRoleBinding リソースをKubernetes設定に追加する必要があります：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: my-cluster-role-binding
roleRef:
  name: view
  kind: ClusterRole
  apiGroup: rbac.authorization.k8s.io
subjects:
  - name: gitlab:project_role:123:maintainer
    kind: Group