一，认证
所有 Kubernetes 集群有两类用户：由Kubernetes管理的ServiceAccounts(服务账户)和(Users Accounts)普通账户。
两种账户的区别：
- 普通帐户是针对(人)用户的，服务账户针对Pod进程
- 普通帐户是全局性。在集群所有namespaces中，名称具有唯一性。
- 通常，群集的普通帐户可以与企业数据库同步，新的普通帐户创建需要特殊权限。服务账户创建目的是更轻量化，允许集群用户为特定任务创建服务账户
- 普通帐户和服务账户的审核注意事项不同。
- 对于复杂系统的配置包，可以包括对该系统的各种组件的服务账户的定义。
1，User Accounts
普通账户是假定被外部或独立服务管理的，由管理员分配 keys用户像使用 Keystone 或 google 账号一样，被存储在包含Usernames和Passwords的list 的文件里.
需要注意:在Kubernetes 中不能通过API调用将普通用户添加到焦群中。
2，Service Accounts
# 获取Service Accounts
kubectl get serviceaccount 或者 [sa]
自动化的三种控制器：
2.1 Service Account Admission Controller
通过 Admission Controller 插件来实现对 pod 修改，它是apiserver 的一部分。创建或更新 pod 时会同步进行修改 pod。当插件处于激活状态(在大多数发行版中都默认情况)创建或修改 pod 时，会按以下操作执行:
- 如果 pod 没有设置 serviceAccount，则将 ServiceAccount设置为 default。
- 确保 pod 引用的 ServiceAccount 存在，否则将会拒绝请求。
- 如果 pod 不包含任何 ImagePullsecrets，则将ServiceAccount的 lmagePullsecrets 会添加到 pod 中。
- 为包含 API访问的 Token 的 pod 添加了一个 volume。
- 把 volumesource 添加到安装在 pod 的每个容器中，挂载在/var/run/secrets/kubernetes.io/serviceaccount.
2.2 Token Controller
2.3 Service Account Controller
Service Account Controller 在namespaces 里管理ServiceAccount，并确保每个有效的 namespaces 中都存在一个名为"default" 的ServiceAccount。
二，授权（RBAC）
角色：Role
代表一个角色，会包会一组权限，没有拒绝规则，只是附加允许。它是 Namespace 级别的资源，只能作用与Namespace之内。
#查春已有的角色信息
kubectl get role -n ingress-nginx -o yaml
集群角色：ClusterRole
功能与 Role 一样，区别是资源类型为集群类型，而 Role 只在Namespace
# 查看某个集群角色的详细信息
kubectl get clusterrole [集群名] -o yaml
角色绑定：RoleBinding
Role 或 ClusterRole 只是用于制定权限集合，具体作用与什么对象上，需要使用 RoleBinding 来进行绑走。
作用于 Namespace 内，可以将 Role 或 ClusterRole 绑定到User、Group、service Account 上.
#查看 rolebinding 信息
kubectl get rolebinding --all-namespaces
或
kubectl get rolebinding -A#查看指定 rolebinding 的配置信息
kubectl get rolebinding <role_binding_name> --all-namespaces -oyaml
或
kubectl get rolebinding <role_binding_name> -A -oyaml
集群角色绑定：ClusterRoleBinding
相关内容同角色绑定！
