• 配置 Kubernetes 访问权限
• 通过用户模拟配置访问
  • 用户模拟工作流
  • RBAC 授权
• 使用 Kubernetes API 访问集群
  • 使用极狐GitLab CLI 来配置本地访问（推荐）
  • 使用个人访问令牌来手动配置本地访问
• 相关主题

授予用户 Kubernetes 访问权限 (Beta)

• 引入于极狐GitLab 16.1，功能标志为 environment_settings_to_graphql、kas_user_access、kas_user_access_project 和 expose_authorized_cluster_agents。此功能处于 Beta 阶段。
• 功能标志 environment_settings_to_graphql 移除于极狐GitLab 16.2。
• 功能标志 kas_user_access、kas_user_access_project 和 expose_authorized_cluster_agents 移除于极狐GitLab 16.2。
• 在极狐GitLab 17.0 中代理链接共享限制从 100 上升到 500。

作为组织中 Kubernetes 集群的管理员，您可以向特定项目或群组的成员授予 Kubernetes 访问权限。

授予访问权限还会激活项目或群组的 Kubernetes Dashboard。

对于私有化部署的实例，请确保您：

• 将您的极狐GitLab 实例和 KAS 托管在同一域上。
• 在极狐GitLab 的子域上托管 KAS。例如，极狐GitLab 在 gitlab.com 上，KAS 在 kas.gitlab.com 上。

配置 Kubernetes 访问权限

当您想要授予用户对 Kubernetes 集群的访问权限时，请配置访问权限。

先决条件：

• Kubernetes 的代理安装在 Kubernetes 集群中。
• 您必须具有开发人员或更高级别的角色。

配置访问权限：

• 在代理配置文件中，使用以下参数定义 user_access 关键字：

  • projects：成员应具有访问权限的项目列表。您可以最多授权 500 个项目。
  • groups：成员应具有访问权限的群组列表。您可以最多授权 500 个群组。它会授权群组的所有子群组。
  • 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 授权

模拟请求需要 ClusterRoleBinding 或 RoleBinding 来识别 Kubernetes 内部的资源权限。请参阅 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

使用 Kubernetes API 访问集群

• 引入于极狐GitLab 16.4。

您可以配置代理以允许极狐GitLab 用户使用 Kubernetes API 访问集群。

先决条件：

• 您有一个配置有 user_access 条目的代理。

使用极狐GitLab CLI 来配置本地访问（推荐）

您可以使用极狐GitLab CLI glab来创建或更新 Kubernetes 配置文件以访问代理的 Kubernetes API。

使用 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 命令将 glab cluster agent get-token 设置为 Kubernetes 工具中的凭据插件以获取令牌。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。您需要此 ID 来构造完整的 API 令牌。
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 地址。在 JihuLab.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 来访问您的集群了。

相关主题

• 架构蓝图