借助RBAC 限制对 Kubernetes 资源的访问

发布时间：2022-08-04 14:41:05 所属栏目：云计算来源：互联网

导读：通过本文，我们将学习如何从头开始重新创建 Kubernetes RBAC 授权模型，并了解Roles、ClusterRoles、ServiceAccounts、RoleBindings 和 ClusterRoleBindings 之间的关系。随着集群中应用程序和资源数量的增加，我们可能需要查看并限制他们相关的权限，从而

　　　　通过本文，我们将学习如何从头开始重新创建 Kubernetes RBAC 授权模型，并了解Roles、ClusterRoles、ServiceAccounts、RoleBindings 和 ClusterRoleBindings 之间的关系。

　　　　随着集群中应用程序和资源数量的增加，我们可能需要查看并限制他们相关的权限，从而避免一些危险操作。这些危险操作往往会严重影响生产环境，有时候，甚至会引起长时间的停机，比如过大的权限导致正常运行的服务被删除。

　　　　正常情况下，我们可能希望限制生产系统仅仅允许少部分人管理以及访问。

　　　　或者，我们可能希望向部署在集群中的维护人员授予一组有限的权限。

　　　　我们可以通过Kubernetes 中的基于角色的访问控制 (RBAC) 来实现上述的需求。

　　　　Kubernetes API
　　　　在讨论RBAC之前，让我们看看授权模型在图中的位置。

　　　　假设我们希望将以下 Pod 部署到 Kubernetes 集群：

　　　　复制
　　　　apiVersion: v1
　　　　kind: Pod
　　　　metadata:
　　　　name: my-pod
　　　　spec:
　　　　containers:
　　　　- name: sise
　　　　  image: learnk8s/app:1.0.0
　　　　  ports:
　　　　  - containerPort: 8080
　　　　1.
　　　　2.
　　　　3.
　　　　4.
　　　　5.
　　　　6.
　　　　7.
　　　　8.
　　　　9.
　　　　10.
　　　　我们可以使用以下命令将 Pod 部署到集群：

　　　　复制
　　　　$ kubectl apply -f pod.yaml
　　　　1.
　　　　当我们输入时kubectl apply，会触发以下的操作。

　　　　kubectl 会：

　　　　1、从KUBECONFIG读取配置。

　　　　2、从 API 中发现 API 和对象。

　　　　3、验证资源客户端（是否有明显的错误？）。

　　　　4、将带有有效负载的请求发送到kube-apiserver。

　　　　当kube-apiserver收到请求时，它不会立即将其存储在 etcd 中。
　　
　　　　在更实际的情况下，API 服务器按顺序执行以下操作：

　　　　1、收到请求后，对用户进行身份验证。

　　　　a. 当验证失败时，通过返回来拒绝请求401 Unauthorized。

　　　　b, 否则，进入下一阶段。

　　　　2、用户已通过身份验证，但他们是否有权访问资源

　　　　a. 如果他们没有权限，请通过返回来拒绝请求403 Forbidden。

　　　　b. 否则，继续。
　　
　　　　其实是可以直接给用户分配权限，只是直接给用户分配权限，少了一层关系，扩展性弱了许多，适合那些用户数量、角色类型少的平台。

　　　　对于通常的系统，比如：存在多个用户拥有相同的权限，在分配的时候就要分别为这几个用户指定相同的权限，修改时也要为这几个用户的权限进行一一修改。有了角色后，我们只需要为该角色制定好权限后，将相同权限的用户都指定为同一个角色即可，便于权限管理。

　　　　对于批量的用户权限调整，只需调整用户关联的角色权限，无需对每一个用户都进行权限调整，既大幅提升权限调整的效率，又降低了漏调权限的概率。

　　　　要了解它是如何工作的，让我们想象一下，我们必须从头开始设计一个授权系统。我们该如何确保用户对特定资源具有写入权限？

　　　　一个简单的实现可能涉及编写一个如下所示的列表：

　　　　复制
　　　　| User | Permission | Resource |
　　　　| ----- | ---------- | -------- |
　　　　| Bob   | read+write |   app1   |
　　　　| Alice |   read   |   app2   |
　　　　| Mo   |   read   |   app2   |
　　　　1.
　　　　2.
　　　　3.
　　　　4.
　　　　5.
　　　　在这个例子中：

　　　　· Bob 有读写权限，可以访问app1但无权访问app2。

　　　　· Mo 和 Alice对app2有只读权限，但是无权访问app1。

　　　　上表适用于少数用户和资源，但一旦开始扩展它就会显示一些限制。

　　　　让我们假设Mo和Alice在同一个Team中，并且他们被授予对app1的读取权限。

　　　　我们必须将以下条目添加到表中：

　　　　复制
　　　　| User     | Permission | Resource |
　　　　| --------- | ---------- | -------- |
　　　　| Bob       | read+write |   app1   |
　　　　| Alice     |   read   |   app2   |
　　　　| Mo       |   read   |   app2   |
　　　　| Alice     |   read   |   app1   |
　　　　| Mo       |   read   |   app1   |
　　　　1.
　　　　2.
　　　　3.
　　　　4.
　　　　5.
　　　　6.
　　　　7.
　　　　这很好，但Alice和Mo是否有相同的访问权限并不明显，因为他们是同一Team的成员。

　　　　在典型的授权系统中我们有用户访问资源图片。

（编辑：开发网_开封站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!

IBM 用混合云和AI 成就	云原生 PostgreSQL 集
领会 Kubernetes 网络	云计算成本节约的重点