什么是 RBAC？
Kubernetes 基于角色的访问控制或 (RBAC) 系统描述了我们如何定义集群中唯一、经过验证的用户或组的不同权限级别。 它使用在 .yaml 文件中定义的细粒度权限集来允许访问特定资源和操作。
从 Kubernetes 1.6 开始，RBAC 默认启用，用户开始时没有权限，因此，权限必须由一个显式授予 admin 到特定的服务或资源。 这些策略对于有效保护您的集群至关重要。 它们允许我们根据用户的角色及其在组织中的职能来指定允许的操作类型。
使用基于角色的访问控制的先决条件
要利用 RBAC，您必须允许用户通过运行以下命令来创建角色：
[email protected]:~# kubectl create clusterrolebinding cluster-admin-binding --clusterrole cluster-admin --user之后，要启动启用了 RBAC 的集群，我们将使用以下标志：
--authorization-mode=RBACRBAC 模型
基本上， RBAC 模型基于三个组件； 角色，集群角色 和 科目. 所有的 k8s 集群都会创建一组默认的 ClusterRoles，代表用户可以放置在其中的公共部门。
- 这 ”编辑”角色允许用户执行基本操作，例如部署 pod。
- 这 ”看法” 让用户可以查看非敏感的特定资源。
- 这 ”admin” 角色让用户管理命名空间。
- 这 ”簇-admin” 允许访问管理集群。
角色
角色由定义资源类型的一组权限的规则组成。 因为没有默认拒绝规则，所以角色只能用于添加对单个虚拟集群内资源的访问。 一个例子看起来像这样。
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）的权限的规则。 一个例子看起来像这样：
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 命令如下所示：
[email protected]:~# kubectl create clusterrole [Options]创建名为 “的 ClusterRole 的命令行示例在下面“，允许用户执行”得到“, “手表“ 和 ”列表” 在 pod 上将是：
[email protected]:~# kubectl create clusterrole pod --verb=get,list,watch --resource=pod角色绑定
一个 角色绑定 是一组指定权限集的配置规则。 它将角色绑定到主题（主题只是用户、一组用户或服务帐户）。 可以使用 RoleBinding 或在集群范围内使用 ClusterRoleBinding 为单个命名空间（虚拟集群）设置这些权限。
让我们允许组“开发运维1” 修改资源中的能力“测试开发” 命名空间：
[email protected]:~# kubectl create rolebinding devops1 --clusterrole=edit --group=devops1 --namespace=dev rolebinding "devops1" created因为我们使用了 RoleBinding，所以这些函数只适用于 RoleBinding 的命名空间。 在这种情况下，“devops1”组中的用户可以查看“testdev”命名空间中的资源，但不能查看其他命名空间中的资源。
集群角色绑定
ClusterRoleBinding 定义了哪些用户有权访问哪些 ClusterRoles。 因为“角色”包含代表一组权限的规则， 集群角色绑定 扩展定义的权限：
- 节点等资源中的唯一命名空间
- 集群中所有命名空间中的资源
- 未定义的资源端点，例如“/foldernames”
默认的 ClusterRoles (admin，编辑，查看）可以使用以下命令创建：
[email protected]:~# kubectl create clusterrolebinding [options]创建 ClusterRoleBinding 的示例 用户1, 用户2，和 组 1 使用 簇-admin 集群角色
[email protected]:~# 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.yamlKubectl 的基本 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”对象。
您可以使用以下命令获取集群中的命名空间列表：
[email protected]:~# kubectl get namespaces NAME STATUS AGE cluster2dev Active 1d cluster2prod Active 4d cluster3dev Active 2w cluster3prod Active 4dKubernetes 总是从三个基本命名空间开始：
- 默认：这是没有明确标识命名空间的对象的默认命名空间（例如，大桶 o’ fun）。
- 立方体系统：这是 Kubernetes 系统本身生成的对象的默认命名空间。
- 公开：这个命名空间是自动创建的，所有人都可以阅读。 此命名空间主要保留给集群使用，以防某些资源应该在整个集群中公开可见和可读。 这个命名空间的公共方面只是一个约定，而不是一个要求。
最后，基于角色的访问控制 (RBAC) 的基本概念是确保可以根据需要或期望将需要特定资源访问权限的用户分配给那些角色、集群角色和集群角色绑定。 这些权限集的粒度经过结构化和启用，可以提高安全性、简化安全策略修改、简化安全审计、提高生产力（RBAC 减少了新员工的入职时间）。 最后，RBAC 允许通过删除不需要的应用程序和较少使用的应用程序的许可成本来进一步降低成本。 总而言之，RBAC 是保护 Kubernetes 基础设施的必要补充。
准备好了解更多信息了吗？
如果您准备好与我们的一位解决方案团队成员通过 聊天，我们可以提供您需要的信息来决定来自 Liquid Web 的运行 Kubernetes 的服务器集群是否能够满足您的需求！
