问题描述
ServiceAccount 的角色及使用；基于 Role 的访问控制；
该笔记将记录：在 Kubernetes Cluster 中，如何使用 RBAC 及 ServiceAccount 进行权限管理，以及常见问题处理；
解决方案
RBAC 授权由以下几部分组成： 1）实体：指 Group、User、ServiceAccount； 2）资源：Pod、Service、Secret； 3）角色：定义了访问资源的行为规则； 4）角色绑定：将角色赋予实体；
资源 <= 角色 <= 角色绑定 => 实体
一个 Role 在 Spec 内可以进行的操作包括：get list watch create update patch delete
角色分为两类： 1）集群范围内的角色：集群角色和他们相应的集群橘色绑定； 2）命名空间范围的角色：角色和角色绑定；
下面讨论如何创建用户自定义的规则，并应用到角色和资源；
场景一、限制 kubectl 命令
当集群部署完成之后，使用 kubectl 命令能够控制整个集群，这是因为 ~/.kube/config 的凭证权限足够高。我们不能直接分发该凭证，应该创建新的碰正限制访问权限；
第一步、检查 RBAC 是否启用
# kubectl api-versions | grep -E ‘^rbac\.’
rbac.authorization.k8s.io/v1
rbac.authorization.k8s.io/v1beta1
启用 RBAC 授权：在启动 kube-apiserver 服务时，指定 –authorization-mode=Example,RBAC 选项
第二步、创建 ServiceAccount 对象
cat > udef-ServiceAccount-PodReader.yaml <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: pod-reader
EOF
kubectl apply -f udef-ServiceAccount-PodReader.yaml
ServiceAccount 相当于传统授权体系的账户，然后将多个 Role（或 ClusterRole）通过 RoleBinding（或 ClusterRoleBinding）绑定到 ServiceAccount 资源；
第三步、创建 Role 对象
该 Role 仅具有读取 Pod 的权限：
cat > udef-Role-PodReader.yaml <<E[……]