在 Azure Stack HCI 和 Windows Server 上的 Azure Kubernetes 服务中使用 Azure AD 和 Kubernetes RBAC 进行访问控制

适用于:Azure Stack HCI 上的 AKS 和 Windows Server

可将 Azure Stack HCI 和 Windows Server 上的 Azure Kubernetes 服务 (AKS) 配置为使用 Azure Active Directory (Azure AD) 进行用户身份验证。 在此配置中,可以使用 Azure AD 身份验证令牌登录到 AKS 群集。 经过身份验证后,可以根据用户标识或组成员身份使用内置 Kubernetes 基于角色的访问控制 (Kubernetes RBAC) 来管理对命名空间和群集资源的访问权限。

本文介绍如何根据 Azure AD 组成员身份使用 AKS 群集中的 Kubernetes RBAC 来控制访问权限。 你将在 Azure AD 中创建一个演示组和用户。 然后,在 AKS 群集中创建角色和 RoleBinding,以授予创建和查看资源的相应权限。

先决条件

在使用 Azure AD 标识设置 Kubernetes RBAC 之前,需要:

  • 一个包含 Azure Stack HCI 和 Windows Server 上的 AKS 的 AKS 群集

    需要一个包含 Azure Stack HCI 和 Windows Server 上的 AKS 的 AKS 群集。 如果需要设置群集,可以查找有关使用 Windows Admin CenterPowerShell 部署 Azure Stack HCI 和 Windows Server 上的 AKS 的说明。

  • Azure Arc 连接

    需要与 Azure Stack HCI 和 Windows Server 上的 AKS 群集建立 Azure Arc 连接。 有关启用 Azure Arc 的说明,请参阅将 Azure Stack HCI 上的 Azure Kubernetes 服务群集连接到已启用 Azure Arc 的 Kubernetes

  • 需要访问以下命令行工具:

    • Azure CLI

      Azure 命令行接口 (Azure CLI) 是一组用来创建和管理 Azure 资源的命令。 若要检查是否已安装 Azure CLI,请打开命令行工具并键入:az -v

      有关安装说明,请参阅如何安装 Azure CLI

    • Kubectl

      使用 Kubernetes 命令行工具 kubectl 可以针对 Kubernetes 群集运行命令。 若要检查是否已安装 kubectl,请打开命令行工具并键入:kubectl version --client。 确保 kubectl 客户端版本至少为 v1.24.0

      有关说明,请参阅 kubectl

    • PowerShell 和 AksHci PowerShell 模块

      PowerShell 是一种跨平台的任务自动化解决方案,由命令行 shell、脚本语言和配置管理框架组成。 如果已安装 Azure Stack HCI 和 Windows Server 上的 AKS,则你可以访问 AksHci PowerShell 模块。

可选的前几个步骤

如果尚未创建包含成员的 Azure AD 组,可能需要创建一个组并添加一些成员,这样才能按照本文中的说明进行操作。

若要演示如何使用 Azure AD 和 Kubernetes RBAC,可为应用程序开发人员创建一个 Azure AD 组,该组可用于演示 Kubernetes RBAC 和 Azure AD 如何控制对群集资源的访问。 在生产环境中,可以使用 Azure AD 租户中的现有用户和组。

在 Azure AD 中创建演示组

首先,使用 az ad group create 命令在租户的 Azure AD 中为应用程序开发人员创建组。 以下示例会将你登录到 Azure 租户,然后创建名为 appdev 的组:

az login
az ad group create --display-name appdev --mail-nickname appdev

将用户添加到组

在 Azure AD 中为应用程序开发人员创建示例组后,让我们将用户添加到 appdev 组。 在本文结束时若要测试 Kubernetes RBAC 集成,可以使用此用户帐户登录到 AKS 群集。

使用 az ad group member add 命令将一个用户添加到在上一部分创建的 appdev 组。 如果已退出会话,则需要使用 az login 重新连接到 Azure。

$AKSDEV_ID = az ad user create --display-name <name> --password <strongpassword> --user-principal-name <name>@contoso.onmicrosoft.com
az ad group member add --group appdev --member-id $AKSDEV_ID

在 AKS 群集资源上为 Azure AD 组创建自定义 Kubernetes RBAC 角色绑定

配置 AKS 群集,以允许 Azure AD 组访问 AKS 群集。 若要添加组和用户以便按照本指南中的步骤进行操作,请参阅在 Azure AD 中创建演示组

  1. 使用 Get-AksHciCredential 命令获取群集管理员凭据。

    Get-AksHciCredential -name <name-of-your-cluster>
    
  2. 使用 kubectl create namespace 命令在 AKS 群集中创建一个命名空间。 以下示例创建名为 dev 的命名空间:

    kubectl create namespace dev
    

    在 Kubernetes 中,角色定义要授予的权限,RoleBinding 将这些权限应用到所需的用户或组。 这些分配可应用于特定的命名空间或整个群集。 有关详细信息,请参阅使用 Kubernetes RBAC 授权

    为 dev 命名空间创建一个角色。 此角色授予对命名空间的完全权限。 在生产环境中,可能需要为不同的用户或组指定更精细的权限。

  3. 创建名为 role-dev-namespace.yaml 的文件并粘贴以下 YAML 清单:

    kind: Role
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: dev-user-full-access
      namespace: dev
    rules:
    - apiGroups: ["", "extensions", "apps"]
      resources: ["*"]
      verbs: ["*"]
    - apiGroups: ["batch"]
      resources:
      - jobs
      - cronjobs
      verbs: ["*"]
    
  4. 使用 kubectl apply 命令创建角色,并指定 YAML 清单的文件名:

    kubectl apply -f role-dev-namespace.yaml
    
  5. 使用 az ad group show 命令获取 appdev 组的资源 ID。 此组将设置为在下一步骤中创建的角色绑定的使用者。

    az ad group show --group appdev --query objectId -o tsv
    

    az ad group 将返回用作 groupObjectId 的值。

    38E5FA30-XXXX-4895-9A00-050712E3673A
    
  6. 创建名为 rolebinding-dev-namespace.yaml 的文件并粘贴以下 YAML 清单。 将为 appdev 组建立 RoleBinding,以使用 role-dev-namespace 角色进行命名空间访问。 在最后一行中,请将 groupObjectId 替换为 az ad group show 命令生成的组对象 ID:

    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: dev-user-access
      namespace: dev
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: dev-user-full-access
    subjects:
    - kind: Group
      namespace: dev
      name: groupObjectId
    

    提示

    若要为单个用户创建 RoleBinding,请指定 kind: User 并将 groupObjectId 替换为上述示例中的用户主体名称 (UPN)。

  7. 使用 kubectl apply 命令创建 RoleBinding,并指定 YAML 清单的文件名:

    kubectl apply -f rolebinding-dev-namespace.yaml
    
    rolebinding.rbac.authorization.k8s.io/dev-user-access created
    

为 AKS 群集资源使用内置 Kubernetes RBAC 角色

Kubernetes 还提供面向用户的内置角色。 这些内置角色包括:

  • 超级用户角色 (cluster-admin)
  • 旨在使用 ClusterRoleBinding 在群集范围授予的角色
  • 旨在使用 RoleBinding 在特定命名空间中授予的角色(admin、edit、view)

若要详细了解内置 Kubernetes RBAC 角色,请访问 Kubernetes RBAC 面向用户的角色

面向用户的角色

默认 ClusterRole 默认 ClusterRoleBinding 说明
cluster-admin system:masters group 允许超级用户访问权限(对任何资源执行任何操作)。 在 ClusterRoleBinding 中使用时,将授予对群集中以及所有命名空间中每个资源的完全控制权。 在 RoleBinding 中使用时,将授予对该角色绑定的命名空间中每个资源(包括该命名空间本身)的完全控制权。
admin 允许进行管理访问,该角色旨在使用 RoleBinding 在命名空间中授予。 如果在 RoleBinding 中使用,则允许对命名空间中的大部分资源进行读取/写入访问,包括能够在该命名空间内创建角色和角色绑定。 此角色不允许对资源配额或命名空间本身进行写入访问。 此角色也不允许对使用 Kubernetes v1.22+ 创建的群集中的终结点进行写入访问。 终结点的写入访问部分提供了详细信息。
编辑 允许对命名空间中的大多数对象进行读/写访问。 此角色不允许查看或修改角色或角色绑定。 但是,允许此角色以命名空间中任何 ServiceAccount 的身份访问机密和运行 Pod,因此可用它获取命名空间中任何 ServiceAccount 的 API 访问级别。 此角色也不允许对使用 Kubernetes v1.22+ 创建的群集中的终结点进行写入访问。 终结点的写入访问部分提供了详细信息。
view 允许进行只读访问并查看命名空间中的大多数对象。 不允许查看角色或角色绑定。 此角色不允许查看机密,因为通过读取机密内容可以访问命名空间中的 ServiceAccount 凭据,这样就会允许以命名空间中任何 ServiceAccount 的身份进行 API 访问(一种特权提升形式)。

将内置 Kubernetes RBAC 角色与 Azure AD 配合使用

  1. 将内置 view Kubernetes RBAC 角色应用于 Azure AD 组:

    kubectl create clusterrolebinding <name of your cluster role binding> --clusterrole=view --group=<Azure AD group object ID>
    
  2. 将内置 view Kubernetes RBAC 角色应用于每个 Azure AD 用户:

    kubectl create clusterrolebinding <name of your cluster role binding> --clusterrole=view --user=<Azure AD user object ID>
    

通过 Azure AD 标识使用群集资源

在 AKS 群集中创建和管理资源时测试所需的权限。 在这些示例中,你将在用户的分配命名空间中计划和查看 pod。 然后,尝试在分配的命名空间外部计划和查看 pod。

  1. 使用作为输入传递给 az ad group member add 命令的 $AKSDEV_ID 用户帐户登录到 Azure。 运行 az connectedk8s proxy 命令打开 AKS 群集的通道:

    az connectedk8s proxy -n <cluster-name> -g <resource-group>
    
  2. 建立代理通道后,打开另一个会话,并在 dev 命名空间中使用 kubectl run 命令计划一个 NGINX pod:

    kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
    

    成功计划 NGINX 后,你会看到以下输出:

    pod/nginx-dev created
    
  3. 现在,请在 dev 命名空间中使用 kubectl get pods 命令查看 Pod。

    kubectl get pods --namespace dev
    

    成功运行 NGINX 后,你会看到以下输出:

    $ kubectl get pods --namespace dev
    
    NAME        READY   STATUS    RESTARTS   AGE
    nginx-dev   1/1     Running   0          4m
    

在分配的命名空间外部创建和查看群集资源

尝试在 dev 命名空间外部查看 pod。 结合 --all-namespaces 标志使用 kubectl get pods 命令。

kubectl get pods --all-namespaces

用户的组成员身份没有允许此操作的 Kubernetes 角色。 由于没有权限,该命令将引发错误。

Error from server (Forbidden): pods is forbidden: User cannot list resource "pods" in API group "" at the cluster scope

后续步骤

请参阅 Azure Stack HCI 和 Windows Server 上的 AKS 中的安全性,详细了解 Azure Stack HCI 和 Windows Server 上的 AKS 的安全性