k8s的ServiceAccount和RBAC机制

基础概念

      k8s中的所有API对象都保存在etcd中 对这些API对象的操作必须通过APIServer进行访问其中一个重要的原因就是必须通过APIserver进行授权工作
      Role：角色,它其实是一组规则,定义了一组对 Kubernetes API 对象的操作权限

      Role 对象指定了它能产生作用的 Namepace 是：mynamespace

      Namespace 是 Kubernetes 项目里的一个逻辑管理单位.不同 Namespace 的 API 对象,在通过 kubectl 命令进行操作的时候,是互相隔离开的

      Subject：被作用者,既可以是“人”,也可以是“机器”,也可以使你在 Kubernetes 里定义的“用户”

      RoleBinding：定义了“被作用者”和“角色”的绑定关系

角色和绑定的组合

     只要是RoleBinding 作用域就只是在定义RoleBinding的名称空间中
     只要是ClusterRoleBinding 作用域就是整个集群范围(所有名称空间)

     Role 只是在当前Role所在的名称空间中定义了一个角色   其它名称空间下并不会出现这个Role
     Role和ClusterRoleBinding表示在Role所在的名称空间中有一个 能操作整个集群资源的角色 在所有名称空间中有效 Role升级为ClusterRole

    ClusterRole 表示同时整个集群(每个名称空间)中定义了一个角色 所有名称空间下都有一个相同名称的Role
    ClusterRole和RoleBinding 只在RoleBinding的名称空间中有效   ClusterRole降级为Role

User和ServiceAccount的授权

      Kubernetes 里的“User”,也就是“用户”,只是一个授权系统里的逻辑概念,它需要通过外部认证服务.比如 Keystone,来提供.或者,你也可以直接给 APIServer 指定一个用户名、密码文件.那么 Kubernetes 的授权系统,就能够从这个文件里找到对应的“用户”了 Uer在k8s中使用的比较少

     Kubernetes 还拥有“用户组”（Group）的概念,也就是一组“用户”的意思

     Kubernetes 负责管理的“内置用户",正是ServiceAccount  在k8s中一般使用ServiceAccount来代替User

    serviceAccount示例流程:

       1.创建一个ServiceAccount资源
       2.创建一个role资源
       3.创建一个rolebinding资源绑定ServiceAccount和role(自动生成对应的secret)
       kubectl describe secret secretobject       查看token信息

k8s在把ServiceAccount和Role进行绑定的时候会自动创建一个Secret对象 

这个 Secret,就是这个 ServiceAccount 对应的,用来跟 APIServer 进行交互的授权文件,我们一般称它为：Token.Token 文件的内容一般是证书或者密码,它以一个 Secret 对象的方式保存在 Etcd当中    这时候用户的 Pod,就可以声明使用这个 ServiceAccount

如果一个 Pod 没有声明 serviceAccountName,Kubernetes 会自动在它的Namespace下创建一个名叫 default 的默认ServiceAccount,然后分配给这个 Pod.但在这种情况下,这个默认 ServiceAccount 并没有关联任何 Role.也就是说,此时它有访问 APIServer 的绝大多数权限.当然,这个访问所需要的 Token,还是默认ServiceAccount 对应的 Secret 对象为它提供的

 在k8s中最普遍的是ServiceAccount,所以Role + RoleBinding + ServiceAccount 的权限分配方式是编写和安装各种插件的时候,会经常用到这个组合.