k8s认证与鉴权_原创精品文档.pdfVIP

k8s认证与鉴权

kubernetes集群的所有的操作基本上都是通过apiserver这个组件进⾏的，它提供HTTPRESTful形式的API供集群内外客户端调⽤。

kubernetes对于访问API来说提供了三个步骤的安全措施：认证、授权、准⼊控制，⽤户使⽤kubectl，client-go或者RESTAPI请求

apiserver时，都是要经过以上三个步骤的校验。认证解决的问题是识别⽤户的⾝份，鉴权是为了解决⽤户有哪些权限，准⼊控制是作⽤于

kubernetes中的对象，通过合理的权限管理，能够保证系统的安全可靠。认证授权过程只存在HTTPS形式的API中，也就是说，如果客户

端使⽤HTTP连接到apiserver，是不会进⾏认证授权的，然⽽apiserver的⾮安全认证端⼝8080已经在v1.12中废弃了，后来全⾯使⽤

HTTPS。

kubernetes的认证机制(Authentication)

kubernetes⽬前所有的认证策略如下所⽰：

X509clientcerts

StaticTokenFile

BootstrapTokens

StaticPasswordFile

ServiceAccountTokens

OpenIdConnectTokens

WebhookTokenAuthentication

AuthticatingProxy

Anonymousrequests

Userimpersonation

Client-gocredentialplugins

可以看到，kubernetes的认证机制⾮常多，要想⼀个个搞清楚也绝⾮易事，本⽂仅分析⼏个⽐较重要且使⽤⼴泛的认证机制。

X509clientcerts

X509是⼀种数字证书的格式标准，现在HTTPS依赖的SSL证书使⽤的就是使⽤的X509格式。X509客户端证书认证⽅式是kubernetes

所有认证中使⽤最多的⼀种，相对来说也是最安全的⼀种，kubernetes的⼀些部署⼯具kubeadm、minkube等都是基于证书的认证⽅式。

客户端证书认证叫作TLS双向认证，也就是服务器客户端互相验证证书的正确性，在都正确的情况下协调通信加密⽅案。⽬前最常⽤的

X509证书制作⼯具有openssl、cfssl等。

ServiceAccountTokens

有些情况下，我们希望在pod内部访问apiserver，获取集群的信息，甚⾄对集群进⾏改动。针对这种情况，kubernetes提供了⼀种特殊的

认证⽅式：serviceaccounts。serviceaccounts是⾯向namespace的，每个namespace创建的时候，kubernetes会⾃动在这个

namespace下⾯创建⼀个默认的serviceaccounts；并且这个serviceaccounts只能访问该namespace的资源。serviceaccounts和pod、

service、deployment⼀样是kubernetes集群中的⼀种资源，⽤户也可以创建⾃⼰的serviceaccounts。

serviceaccounts主要包含了三个内容：namespace、token和ca，每个serviceaccounts中都对应⼀个secrets，namespace、token和ca

信息都是保存在secrets中且都通过base64编码的。namespace指定了pod所在的namespace，ca⽤于验证apiserver的证书，token⽤

作⾝份验证，它们都通过mount的⽅式保存在pod的⽂件系统中，其三者都是保存在/var/run/secrets/kubernetes.io/serviceaccount/⽬录

下。

kubernetes中有多种认证⽅式，上⾯讲了最常使⽤的两种认证⽅式，X509clientcerts认证⽅式是⽤在⼀些客户端访问apiserver以及集群

组件之间访问时使⽤，⽐如kubectl请求apiserver时。serviceaccounts是⽤在pod中访问apiserver时进⾏认证的，⽐如使⽤⾃定义

controller时。

认证解决的问题是识别⽤户的⾝份，那kubernetes中都有哪⼏种⽤户？⽬前kub