共计 7475 个字符，预计需要花费 19 分钟才能阅读完成。
正文
12.1. 了解认证机制
启动 API 服务器时，通过命令行选项可以开启认证插件。
12.1.1. 用户和组
了解用户：
分为两种连接到 api 服务器的客户端：
1. 真实的人
2.pod，使用一种称为 ServiceAccount 的机制
了解组：
认证插件会连同用户名，和用户 id 返回组，组可以一次性给用户服务多个权限，不用单次赋予，
system:unauthenticated 组：用于所有认证插件都不会认证客户端身份的请求。
system:authenticated 组：会自动分配给一个成功通过认证的用户。
system:serviceaccount 组：包含 所有在系统中的 serviceaccount。
system:serviceaccount：<namespace> 组：包含了所有在特定命名空间中的 serviceAccount。
12.1.2 ServiceAccount 介绍
每个 pod 中都包含 /var/run/secrets/kubernetes.io/serviceaccount/token 文件，如下图所示，文件内容用于对身份进行验证，token 文件持有 serviceaccount 的认证 token。
应用程序使用 token 去连接 api 服务器时，认证插件会对 serviceaccount 进行身份认证，并将 serviceaccount 的用户名传回到 api 服务器内部。
serviceaccount 的用户名格式如下：
system:serviceaccount:<namespace>:<service account name>
ServiceAccount 是运行在 pod 中的应用程序，和 api 服务器身份认证的一中方式 。
了解 ServiceAccount 资源
ServiceAcount 作用在单一命名空间，为每个命名空间创建默认的 ServiceAccount。
多个 pod 可以使用相同命名空间下的同一的 ServiceAccount，
ServiceAccount 如何与授权文件绑定
在 pod 的 manifest 文件中，可以指定账户名称的方式，将一个 serviceAccount 赋值给一个 pod，如果不指定，将使用该命名空间下默认的 ServiceAccount.
可以 将不同的 ServiceAccount 赋值给 pod，让 pod 访问不同的资源。
12.1.3 创建 ServiceAccount
为了集群的安全性，可以手动创建 ServiceAccount，可以限制只有允许的 pod 访问对应的资源。
创建方法如下：
使用 describe 来查看 ServiceAccount。
查看该 token，
Name: yaohong-token-qhbxn
Namespace: default
Labels: <none>
Annotations: kubernetes.io/service-account.name: yaohong
kubernetes.io/service-account.uid: a3d0d2fe-bb43-11e9-ac1e-005056870b4d
Type: kubernetes.io/service-account-token
Data
====
ca.crt: 1342 bytes
namespace: 7 bytes
token: eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6Inlhb2hvbmctdG9rZW4tcWhieG4iLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoieWFvaG9uZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImEzZDBkMmZlLWJiNDMtMTFlOS1hYzFlLTAwNTA1Njg3MGI0ZCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0Onlhb2hvbmcifQ.BwmbZKoM95hTr39BuZhinRT_vHF-typH4anjkL0HQxdVZEt_eie5TjUECV9UbLRRYIqYamkSxmyYapV150AQh-PvdcLYPmwKQLJDe1-7VC4mO2IuVdMCI_BnZFQBJobRK9EdPdbZ9uxc9l0RL5I5WyWoIjiwbrQvtCUEIkjT_99_NngdrIr7QD9S5SxHurgE3HQbmzC6ItU911LjmxtSvBqS5NApJoJaztDv0cHKvlT67ZZbverJaStQdxr4yiRbpSycRNArHy-UZKbNQXuzaZczSjVouo5A5hzgSHEBBJkQpQ6Tb-Ko5XGjjCgV_b9uQvhmgdPAus8GdFTTFAbCBw
12.1.4 将 ServiceAccount 分配给 pod
在 pod 中定义的 spec.serviceAccountName 字段上设置，此字段必须在 pod 创建时设置后续不能被修改。
自定义 pod 的 ServiceAccount 的方法如下图
12.2 通过基于角色的权限控制加强集群安全
12.2.1. 介绍 RBAC 授权插件
RBAC 授权插件将用户角色作为决定用户能否执行操作的关机因素 。
12.2.2 介绍 RBAC 授权资源
RBAC 授权规则通过四种资源来进行配置的，他们可以分为两组：
Role 和 ClusterRole，他们决定资源上可执行哪些动词。
RoleBinding 和 ClusterRoleBinding，他们将上述角色绑定到特定的用户，组或者 ServiceAccounts 上。
Role 和 RoleBinding 是 namespace 级别资源
ClusterRole 和 ClusterRoleBinding 是集群级别资源
12.2.3 使用 Role 和 RoleBinding
Role 资源定义了哪些操作可以在哪些资源上执行，
创建 Role
service-reader.yml
在 kube-system 中创建 Role
查看该 namespace 下的 role
绑定角色到 ServiceAccount
将 service-reader 角色绑定到 default ServiceAccount
12.2.4 使用 ClusterRole 和 ClusterRoleBinding
查看集群 ClusterRole
创建 ClusterRole
查看 yaml 文件
创建 clusterRoleBinding
12.2.5 了解默认的 ClusterRole 和 ClusterRoleBinding
如下所示使用 kubectl get clusterroles 和 kubectl get clusterrolesbinding 可以获取 k8s 默认资源。
用 edit ClusterRole 允许对资源进行修改
用 admin ClusterRole 赋予一个命名空间全部的权限
：
