Kubernetes生产实践系列之一：Kubernetes基于RBAC的访问权限控制

一、前言

在Kubernetes的使用过程中，用户和集群各类资源对象的关系是最初始也是最基本的需要解决的问题。在Kubernetes的体系中，用户账号叫做subject，包括两个种类：User和ServiceAccount，前者给个人使用，后者给Pod使用；而所有的namespace级别和集群级别的资源叫做object；Kubernetes使用RBAC机制操作subject和object，来向外部提供干预系统状态的干预者的认证和授权机制。在v1.6之前，Kubernetes使用ABAC进行权限管理，在v1.8之后RBAC机制进入稳定阶段。

通过使用RBAC机制，是的系统管理员、研发、测试等不同集群使用者就能更细粒度使用和管理集群的资源，满足多namespace、多种权限(只读、读写、跨namespace读/写)等需求。

转载自https://blog.youkuaiyun.com/cloudvtech

二、用户账户的建立和认证

集群外部实体(管理员、namespace用户或者服务研发)和集群内部实体(Kubernetes系统和部署于集群上应用)都会有访问和调控系统资源的需求，外部实体使用User(Kubernetes有一个User类型的资源来代表)进行集群访问接入，内部实体(Pod里面的进程)使用ServiceAccount进行集群访问接入。User账户是没有namespace属性的，ServiceAccount账户是有namespace属性的。

对于外部用户账户，实际上，使用集群ca证书和用户的签名证书为用户颁发的集群访问证书，只是表明外部用户被认证过能访问API Server接口，但是在管理员将这个用户通过Kind:User注册到集群之前， API Server是不会响应资源操作请求的。除了上述使用签名证书方式来验证外部用户(用户的名字在制作证书的时候的CN属性里面填写)之外，还可以通过静态token文件或者静态密码文件进行外部用户验证，但是这要求在API Server启动的时候指定这些静态文件。

对于内部用户账户ServiceAccount(sa)，可以用于授权Pod里面的进程访问API Server，它所对应的secret的token可以用于集群外部进程访问API Server。API Server被创建之后，token controller会为这个sa建立一个secret object：

在POD启动时，如果指定使用该sa，则sa对应secret里面的token和ca文件会被自动挂载到容器的/var/run/secrets/kubernetes.io/serviceaccount/目录：

Containers:

  nginx:

    Container ID:   docker://d5fee046729b8010c7fa0f6d7abd0c6bf08238dce0041979124bd143e6b3eb53

    Image:          172.2.2.11:5000/nginx:1.14

    ......

    Mounts:

      /var/run/secrets/kubernetes.io/serviceaccount from default-token-khs2h (ro)

......

Volumes:

  default-token-khs2h:

    Type:        Secret (a volume populated by a Secret)

    SecretName:  default-token-khs2h

    Optio