ユーザーにKubernetesへのアクセスを付与する

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

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

GitLab Self-Managedインスタンスの場合は、次のいずれかを実行してください:

• GitLabインスタンスとKASを同じドメインでホストします。
• KASをGitLabのサブドメインでホストします。たとえば、GitLabがgitlab.comで、KASがkas.gitlab.comである場合です。

Kubernetesアクセスを設定する

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

前提要件:

• Kubernetes用エージェントがKubernetesクラスタにインストールされている必要があります。
• デベロッパーロール以上が必要です。

アクセスを設定するには:

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

  • projects: メンバーがアクセスできるプロジェクトのリスト。最大500個のプロジェクトを承認できます。
  • groups: メンバーがアクセスできるグループのリスト。最大500個のグループを承認できます。グループとそのすべて子孫へのアクセスを許可します。
  • access_as: エージェントのIDでアクセスする場合、値は{ 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またはsession_cookieのいずれか。Ultimateのみです。

設定ファイルの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認可

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

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

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

Kubernetes APIでクラスタにアクセスする

エージェントを設定して、GitLabユーザーがKubernetes APIでクラスタにアクセスできるようにすることができます。

前提要件:

• user_accessエントリで設定されたエージェントがあります。

GitLab CLIでローカルアクセスを設定する（推奨）

GitLab CLI glabを使用して、エージェントKubernetes APIにアクセスするためのKubernetes設定ファイルを作成または更新できます。

glab cluster agentコマンドを使用して、クラスタ接続を管理します:

1. プロジェクトに関連付けられているすべてのエージェントのリストを表示します:

glab cluster agent list --repo '<group>/<project>'

# If your current working directory is the Git repository of the project with the agent, you can omit the --repo option:
glab cluster agent list

1. 出力の最初の列に表示される数値エージェントIDを使用して、kubeconfigを更新します:

glab cluster agent update-kubeconfig --repo '<group>/<project>' --agent '<agent-id>' --use-context

1. kubectlまたは優先するKubernetesツールで更新を確認します:

kubectl get nodes

update-kubeconfigコマンドは、トークンを取得するためのKubernetesツールの認証情報プラグインとしてglab cluster agent get-tokenを設定します。get-tokenコマンドは、当日終了まで有効なパーソナルアクセストークンを作成して返します。Kubernetesツールは、トークンの期限が切れるか、APIが認可エラーを返すか、プロセスが終了するまで、キャッシュにトークンを保存します。後続のすべてのKubernetesツールの呼び出しで、新しいトークンが作成されると予想されます。

glab cluster agent update-kubeconfigコマンドは、多数のコマンドラインフラグをサポートしています。サポートされているすべてのフラグを表示するには、glab cluster agent update-kubeconfig --helpを使用します。

次に例を示します:

# When the current working directory is the Git repository where the agent is registered the --repo / -R flag can be omitted
glab cluster agent update-kubeconfig --agent '<agent-id>'

# When the --use-context option is specified the `current-context` of the kubeconfig file is changed to the agent context
glab cluster agent update-kubeconfig --agent '<agent-id>' --use-context

# The --kubeconfig flag can be used to specify an alternative kubeconfig path
glab cluster agent update-kubeconfig --agent '<agent-id>' --kubeconfig ~/gitlab.kubeconfig

パーソナルアクセストークンを使用してローカルアクセスを手動で設定する

有効期間の長いパーソナルアクセストークンを使用して、Kubernetesクラスタへのアクセスを設定できます:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。

2. 左側のサイドバーで、操作 > Kubernetesクラスターを選択し、アクセスするエージェントの数値IDを取得します。完全なAPIトークンを構築するには、IDが必要です。

3. k8s_proxyのスコープを持つパーソナルアクセストークンを作成します。完全なAPIトークンを構築するには、アクセストークンが必要です。

4. クラスタにアクセスするためのkubeconfigエントリを構築します:

   1. 適切なkubeconfigが選択されていることを確認してください。たとえば、KUBECONFIG環境変数を設定できます。

   2. GitLab KASプロキシクラスタをkubeconfigに追加します:

      kubectl config set-cluster <cluster_name> --server "https://kas.gitlab.com/k8s-proxy"

      server引数は、GitLabインスタンスのKASアドレスを指します。GitLab.comでは、これはhttps://kas.gitlab.com/k8s-proxyです。エージェントを登録すると、インスタンスのKASアドレスを取得できます。

   3. 数値エージェントIDとパーソナルアクセストークンを使用して、APIトークンを構築します:

      kubectl config set-credentials <gitlab_user> --token "pat:<agent-id>:<token>"

   4. コンテキストを追加して、クラスタとユーザーを結合します:

      kubectl config set-context <gitlab_agent> --cluster <cluster_name> --user <gitlab_user>

   5. 新しいコンテキストをアクティブにします:

      kubectl config use-context <gitlab_agent>

5. 設定が機能することを確認します:

   kubectl get nodes

設定されたユーザーは、Kubernetes APIでクラスタにアクセスできます。

関連トピック

• アーキテクチャブループリント
• Kubernetes向けダッシュボード