目录一、简介二、用户分类三、K8s角色&角色绑定（以ServiceAccount展开讲解）1）授权介绍2）角色（Role和ClusterRole）3）角色绑定（RoleBinding和ClusterRoleBinding）1、Role角色绑定ServiceAccount2、ClusterRole角色绑定ServiceAccount四、实战1）User1、创建K8S用户2、对用户授权2）Group1、创建K8S用户和用户组2、对组授权3）ServiceAccount4）为ServiceAccount生成Token5）默认的Token五、总结一、简介kubernetes集群相关所有的交互都通过ap

目录一、简介二、用户分类三、K8s角色&角色绑定（以ServiceAccount展开讲解）1）授权介绍2）角色（Role和ClusterRole）3）角色绑定（RoleBinding和ClusterRoleBinding）1、Role角色绑定ServiceAccount2、ClusterRole角色绑定ServiceAccount四、实战1）User1、创建K8S用户2、对用户授权2）Group1、创建K8S用户和用户组2、对组授权3）ServiceAccount4）为ServiceAccount生成Token5）默认的Token五、总结一、简介kubernetes集群相关所有的交互都通过ap

ServiceAccountServiceAccount是给运行在Pod的程序使用的身份认证，Pod容器的进程需要访问APIServer时用的就是ServiceAccount账户。ServiceAccount仅局限它所在的namespace，每个namespace创建时都会自动创建一个defaultserviceaccount。创建Pod时，如果没有指定ServiceAccount，Pod则会使用defaultServiceAccount。 通过以下命令可以查看我们前面创建chesterns这个namespace下的serviceaccount与对应的secretkubectldescribe

ServiceAccountServiceAccount是给运行在Pod的程序使用的身份认证，Pod容器的进程需要访问APIServer时用的就是ServiceAccount账户。ServiceAccount仅局限它所在的namespace，每个namespace创建时都会自动创建一个defaultserviceaccount。创建Pod时，如果没有指定ServiceAccount，Pod则会使用defaultServiceAccount。 通过以下命令可以查看我们前面创建chesterns这个namespace下的serviceaccount与对应的secretkubectldescribe

ServiceAccount为Pod中运行的进程提供了一个身份，Pod内的进程可以使用其关联服务账号的身份，向集群的APIServer进行身份认证。当创建Pod的时候规范下面有一个 spec.serviceAccount 的属性用来指定该Pod使用哪个ServiceAccount，如果没有指定的话则默认使用default这个sa。然后通过投射卷，在Pod的目录 /run/secrets/kubernetes.io/serviceaccount/ 下有一个 token 令牌文件。我们通过RBAC对该sa授予了什么权限，那么容器里的应用拿着这个token后，就具备了对应的权限。但是需要注意的是不同

ServiceAccount为Pod中运行的进程提供了一个身份，Pod内的进程可以使用其关联服务账号的身份，向集群的APIServer进行身份认证。当创建Pod的时候规范下面有一个 spec.serviceAccount 的属性用来指定该Pod使用哪个ServiceAccount，如果没有指定的话则默认使用default这个sa。然后通过投射卷，在Pod的目录 /run/secrets/kubernetes.io/serviceaccount/ 下有一个 token 令牌文件。我们通过RBAC对该sa授予了什么权限，那么容器里的应用拿着这个token后，就具备了对应的权限。但是需要注意的是不同