K8S认证、授权与准入控制(RBAC)详解

前言

1. RBAC (Role-Based Access Control，基于角色的访问控制）是一种新型、灵活且使用广泛的访问控制机制，它将权限授予“角色”（role）之上，这一点有别于传统访问控制机制中 将权限直接赋予使用者的方式，简单点来说就是将权限绑定到role中，然后用户和role绑定，这样用户就拥有了和role一样的权限。
2. 在任何将资源或服务提供给有限使用者的系统上，认证和授权都是两个必不可少的功 能，认证用于身份鉴别，而授权则实现权限分派 。 Kubemetes 以插件化的方式实现了这两种 功能，且分别存在多种可用的插件。 另外，它还支持准入控制机制，用于补充授权机制以实现更精细的访问控制功能 。
3. API Server 作为 Kubernetes 集群系统的网关，是访问及管理资源对象的唯一人口，所有需要访问集群资源的组件，以及此前使用的 kubectl 命令等都要经由此网关进行集群访问和管理。
4. RBAC使用rbac.authorization.k8s.io API Group 来实现授权决策，允许管理员通过 Kubernetes API 动态配置策略，要启用RBAC，需要在 apiserver 中添加参数--authorization-mode=RBAC，如果使用的kubeadm安装的集群，都默认开启了RBAC，可以通过查看 Master 节点上 apiserver 的静态Pod定义文件：

   [root@node-01 ~]# cat /etc/kubernetes/manifests/kube-apiserver.yaml 
   ···
   - --authorization-mode=Node,RBAC
   ···

5. 如果是二进制的方式搭建的集群，添加这个参数过后，记得要重启 apiserver 服务。

RBAC API资源对象

Kubernetes有一个很基本的特性就是它的所有资源对象都是模型化的 API 对象，允许执行增、删、改、查等操作，比如下面的这下资源：

• Pods
• ConfigMaps
• Deployments
• Nodes
• Secrets
• Namespaces

上面这些资源对象的可能存在的操作有：

• create
• get
• delete
• list
• update
• edit
• watch
• exec

用户账户和用户组

Kubernetes 并不会存储由认证插件从客户端请求中提取出的用户及所属组的信息，它们仅仅用于检验用户是否有权限执行其所请求的操作。

客户端访问API服务的途径通常有三种：kubectl、客户端库或者直接使用 REST接口进行请求。

而可以执行此类请求的主体也被 Kubernetes 分为两类：现实中的“人”和 Pod 对象， 它们的用户身份分别对应于常规用户 (User Account ）和服务账号 （ Service Account） 。

• Use Account（用户账号）：一般是指由独立于Kubernetes之外的其他服务管理的用 户账号，例如由管理员分发的密钥、Keystone一类的用户存储（账号库）、甚至是包 含有用户名和密码列表的文件等。Kubernetes中不存在表示此类用户账号的对象， 因此不能被直接添加进 Kubernetes 系统中 。
• Service Account（服务账号）：是指由Kubernetes API 管理的账号，用于为Pod 之中的服务进程在访问Kubernetes API时提供身份标识（ identity ） 。Service Account通常要绑定于特定的命名空间，它们由 API Server 创建，或者通过 API 调用于动创建 ，附带着一组存储为Secret的用于访问API Server的凭据。
  

Kubernetes 有着以下几个内建的用于特殊目的的组 。

• system:unauthenticated