1.4.4　微服务验证和授权

身份验证和授权也与安全相关，通过限制受信任用户可访问有限的Kubernetes资源来保障。组织具有多种验证用户身份的方法。Kubernetes也支持许多常见的身份验证方案，例如X.509证书和HTTP基本身份验证（不是很安全），以及通过webhook的外部身份验证服务器，可让你最终控制身份验证过程。身份验证过程仅将请求的凭据与身份（原始用户或模拟用户）进行匹配，而允许该用户执行哪些操作则由授权过程控制，接下来了解一下基于角色的访问控制。

基于角色的访问控制

基于角色的访问控制（Role-based Access Control，RBAC）不是必需的！你可以使用Kubernetes中的其他机制进行授权。但是，RBAC是最佳实践，它有两个概念：角色和绑定。角色定义了一组特定权限的规则。角色有两种：Role适用于单个命名空间，ClusterRole适用于集群中的所有命名空间。

下面是默认命名空间中的一个角色，该角色允许获取、监控和列出所有Pod。每个角色都有三部分——API组、资源和动作：

集群角色也有类似的配置，除了没有命名空间字段，因为它适用于所有命名空间。

绑定会将一系列主题（用户、用户组或服务账户）与角色相关联。绑定有两种类型，RoleBinding和ClusterRoleBinding，它们分别对应于Role和ClusterRole。

有趣的是，你可以将ClusterRole绑定到单个命名空间中的主题。这对于定义需要应用到多个命名空间的角色很方便，一旦创建了集群角色，你可以将它们绑定到特定命名空间中的特定主题。

集群角色绑定也是类似的配置，但是注意它必须绑定一个集群角色，并且始终应用于整个集群。

注意，RBAC用于授予对Kubernetes资源的访问权限。它可以管理对服务端点的访问，但是你可能仍需要微服务中的细粒度授权。