什么是 Kubernetes RBAC 授权

什么是 RBAC?

Kubernetes 基于角色的访问控制或 (RBAC) 系统描述了我们如何定义集群中唯一、经过验证的用户或组的不同权限级别。 它使用在 .yaml 文件中定义的细粒度权限集来允许访问特定资源和操作。

从 Kubernetes 1.6 开始,RBAC 默认启用,用户开始时没有权限,因此,权限必须由 admin 到特定的服务或资源。 这些策略对于有效保护您的集群至关重要。 它们允许我们根据用户的角色及其在组织中的职能来指定允许的操作类型。

使用基于角色的访问控制的先决条件

要利用 RBAC,您必须允许用户通过运行以下命令来创建角色:

root@test:~# kubectl create clusterrolebinding cluster-admin-binding 
 --clusterrole cluster-admin --user

之后,要启动启用了 RBAC 的集群,我们将使用以下标志:

--authorization-mode=RBAC

RBAC 模型

基本上, RBAC 模型基于三个组件; 角色,集群角色科目. 所有的 k8s 集群都会创建一组默认的 ClusterRoles,代表用户可以放置在其中的公共部门。

  • 这 ”编辑”角色允许用户执行基本操作,例如部署 pod。
  • 这 ”看法” 让用户可以查看非敏感的特定资源。
  • 这 ”admin” 角色让用户管理命名空间。
  • 这 ”簇-admin” 允许访问管理集群。

角色

角色由定义资源类型的一组权限的规则组成。 因为没有默认拒绝规则,所以角色只能用于添加对单个虚拟集群内资源的访问。 一个 example 看起来像这样。

kind: Role
 apiVersion: rbac.authorization.domain.com/home
 metadata:
 namespace: testdev
 name: dev1
 rules:
 - apiGroups: [""] # "" indicates the core API group
 resources: ["pods"]
 verbs: ["get", "watch", "list"]

在这种情况下,角色定义用户 (开发者1) 可以使用“得到”, “手表“ 或者 ”列表” 中一组 pod 的命令测试开发”命名空间。

集群角色

一种 集群角色 可用于授予与角色相同的权限,但由于它们是集群范围的,因此它们还可用于授予对以下内容的更广泛的访问权限:

  • 集群范围的资源(如节点)
  • 非资源端点(如名为“/test”的文件夹)
  • 所有命名空间中和跨命名空间的命名空间资源(如 pod)。 我们需要运行 kubectl get pods --all-namespaces

它包含定义一组跨资源(如节点或 pod)的权限的规则。 一个 example 看起来像这样:

kind: ClusterRole
 apiVersion: rbac.authorization.k8s.io/v1
 metadata:
 # "namespace" omitted since ClusterRoles are not namespaced
 name: secret-reader
 rules:
 - apiGroups: [""]
 resources: ["secrets"]
 verbs: ["get", "watch", "list"]

默认 ClusterRole 命令如下所示:

root@test:~# kubectl create clusterrole [Options]

命令行 example 创建一个名为““,允许用户执行”得到“, “手表“ 和 ”列表” 在 pod 上将是:

root@test:~# kubectl create clusterrole pod --verb=get,list,watch --resource=pod

角色绑定

一种 角色绑定 是一组指定权限集的配置规则。 它将角色绑定到主题(主题只是用户、一组用户或服务帐户)。 可以使用 RoleBinding 或在集群范围内使用 ClusterRoleBinding 为单个命名空间(虚拟集群)设置这些权限。

让我们允许组“开发运维1” 修改资源中的能力“测试开发” 命名空间:

root@test:~# kubectl create rolebinding devops1 --clusterrole=edit --group=devops1 --namespace=dev rolebinding "devops1" created

因为我们使用了 RoleBinding,所以这些函数只适用于 RoleBinding 的命名空间。 在这种情况下,“devops1”组中的用户可以查看“testdev”命名空间中的资源,但不能查看其他命名空间中的资源。

集群角色绑定

ClusterRoleBinding 定义了哪些用户有权访问哪些 ClusterRoles。 因为“角色”包含代表一组权限的规则, 集群角色绑定 扩展定义的权限:

  • 节点等资源中的唯一命名空间
  • 集群中所有命名空间中的资源
  • 未定义的资源端点,例如“/foldernames”

默认的 ClusterRoles (admin,编辑,查看)可以使用以下命令创建:

root@test:~# kubectl create clusterrolebinding [options]

一个 example 为创建 ClusterRoleBinding 用户1, 用户2,和 组 1 使用 簇-admin 集群角色

root@test:~# kubectl create clusterrolebinding cluster-admin --clusterrole=cluster-admin --user=user1 --user=user2 --group=group1

配置映射

什么是配置映射?

configMap 是一种可以轻松地将配置数据附加到 pod 的资源。 存储在 ConfigMap 中的信息用于将配置数据与其他内容分开,以保持图像/pod 的可移植性。

如何创建 ConfigMap?

要创建 configmap,我们只需使用以下命令:

kubectl create configmap <map-name> <data-source>

让我们创建一个 默认.yaml 创建 ConfigMap 的文件:

kubectl create -f default.yaml /configmaps/location/basic.yaml

Kubectl 的基本 RBAC 命令

注意如果 RBAC 配置不正确,这些命令将出错。

kubectl get roles
kubectl get rolebindings
kubectl get clusterroles
kubectl get clusterrolebindings
kubectl get clusterrole system:node -o yaml

命名空间

命名空间 用于在大量用户或空间中定义、分离和识别资源集群。 只有当您拥有一组非常多样化的集群、位置或用户时,您才应该使用命名空间。 它们用于公司拥有多个用户或团队的环境,这些用户或团队分布在不同的项目、地点或部门。 命名空间还提供了一种方法来防止跨大量集群的命名冲突。

在命名空间中,一个对象可以用更短的名称来标识,例如“cluster1”,也可以像“US.MI.LAN.DC2.S1.R13.K5.ProdCluster1”一样复杂,但只能有一个“ cluster1′ 或该命名空间内的 ‘US.MI.LAN.DC2.S1.R13.K5.ProdCluster1’。 因此,命名空间内的资源名称必须是唯一的,但不能跨越命名空间。 您可以有多个不同的命名空间,它们都可以包含一个“cluster1”对象。

您可以使用以下命令获取集群中的命名空间列表:

root@test:~# kubectl get namespaces
 NAME STATUS AGE
 cluster2dev Active 1d
 cluster2prod Active 4d
 cluster3dev Active 2w
 cluster3prod Active 4d

Kubernetes 总是从三个基本命名空间开始:

  • 默认:这是没有明确标识命名空间的对象的默认命名空间(例如,大桶 o’ fun)。
  • kube 系统:这是 Kubernetes 系统本身生成的对象的默认命名空间。
  • kube-公共:这个命名空间是自动创建的,所有人都可以阅读。 此命名空间主要保留给集群使用,以防某些资源在整个集群中是公​​开可见和可读的。 这个命名空间的公共方面只是一个约定,而不是一个要求。

最后,基于角色的访问控制 (RBAC) 的基本概念是确保可以根据需要或期望将需要特定资源访问权限的用户分配给那些角色、集群角色和集群角色绑定。 这些权限集的粒度经过结构化和启用,可以提高安全性、简化安全策略修改、简化安全审计、提高生产力(RBAC 减少了新员工的入职时间)。 最后,RBAC 允许通过删除不需要的应用程序和较少使用的应用程序的许可成本来进一步降低成本。 总而言之,RBAC 是保护 Kubernetes 基础设施的必要补充。

准备好了解更多了吗?

如果您准备好与我们的一位解决方案团队成员通过 聊天,我们可以提供您需要的信息来决定来自 Liquid Web 的运行 Kubernetes 的服务器集群是否能够满足您的需求!