深入剖析Kubernetes-基于角色的权限控制
Kubernetes 中所有的 API 对象，都保存在 Etcd 里。可是，对这些 API 对象的操作，却一定都是通过访问 kube-apiserver 实现的。其中一个非常重要的原因，就是你需要APIServer 来帮助你做授权工作。
而在 Kubernetes 项目中，负责完成授权（Authorization）工作的机制，就是 RBAC：基于角色的访问控制（Role-Based Access Control）。
RBAC中三个最基本的概念：
- Role：角色，它其实是一组规则，定义了一组对Kubernetes API 对象的操作权限。
- Subject：被作用者，既可以是“人”，也可以是“机器”，也可以使你在 Kubernetes 里定义的“用户”。
- RoleBinding：定义了“被作用者”和“角色”的绑定关系。而这三个概念，其实就是整个 RBAC 体系的核心所在。
实际上，Role 本身就是一个 Kubernetes 的 API 对象，定义如下所示：
RoleBinding 本身也是一个 Kubernetes 的 API 对象。它的定义如下所示：
Kubernetes 里的“User”，也就是“用户”，只是一个授权系统里的逻辑概念。它需要通过外部认证服务，比如 Keystone，来提供。或者，你也可以直接给 APIServer 指定一个用户名、密码文件。那么 Kubernetes 的授权系统，就能够从这个文件里找到对应的“用户”了。
当然，在大多数私有的使用环境中，我们只要使用 Kubernetes 提供的内置“用户”，就足够了。