Kubernetes API Server 的认证机制

认证


开启 TLS时,所有的请求都需要首先认证。Kubernetes支持多种认证机制,并支持同时开启多个认证插件(只要有一个认证通过即可)。如果认证成功,则用户的 username 会传入授权模块做进一步授权验证;而对于认证失败的请求则返回 HTTP 401。

当apiserver启动的时候,其实有两个和安全相关的配置,一个叫insecure-port,一个叫secure-port,早期大家很习惯的将insecure-port打开,经过insecure-port端口所有的请求其实是没有做任何的安全校验的,也就是认证,鉴权这些逻辑是不走的,这样就面临着一个危险,所有的request是没有认证的,不管是谁发的,它有没有权限,它都会被接受,这很可能就会有一些恶意的请求。

所以现在在非生产环境也会将insecure端口关掉。

另外一个是secure port,secure-port设置之后所有的认证,鉴权这些逻辑都要走。

 

认证插件


针对开放式的框架,它一定会支持很多很多的认证方式。

X509 证书

  • 使用X509客户端证书只需要 API Server启动时配置--client-ca-file=SOMEFILE。在证书认证时,其CN 域用作用户名,而组织机构域则用作 group 名。

证书一般会有key和cert,cert在签发的时候是发给什么机构,哪个人的。这样你带着一个证书来访问apiserver的时候,它有签发你证书的ca文件,它就能够解析出来你的certificates,它就能够知道你是谁。

静态Token 文件

  • 使用静态 Token 文件认证只需要 API Server启动时配置--token-auth-file=SOMEFILE。
  • 该文件为 csv格式,每行至少包括三列 token,username,user id,token,user,uid,"group1,group2,group3"

apiserver启动的时候要配置一个token-auth-file,在这个csv文件里面配置用户名,用户id,以及对应的token,和用户属于哪些组配置在这个scv文件里面,它有点像简化的数据库,其实也即是将用户名和对应的token发到这里面,然后在apiserver启动的时候加载这个文件,那apiserver就知道我这个集群可以接受哪些用户请求,你带着用户token过来,它就能够判断这个token是不是合法的,如果合法就知道对应的user是谁,它就可以将这个请求接受掉了。

引导 Token

  • 为了支持平滑地启动引导新的集群,Kubernetes 包含了一种动态管理的持有者令牌类型,称作启动引导令牌(Bootstrap Token)。
  • 这些令牌以 Secret 的形式保存在kube-system名字空间中,可以被动态管理和创建。
  • 控制器管理器包含的 TokenCleaner控制器能够在启动引导令牌过期时将其删除。
  • 在使用kubeadm 部署Kubernetes 时,可通过 kubeadm token list 命令查询。

在k8s启动的时候有bootstrap token,它也是可以做认证的。

静态密码文件

  • 需要API Server 启动时配置--basic-auth-file=SOMEFILE,文件格式为cSV,每行至少三列 password,user,uid,后面是可选的group名 password,user,uid,"group1,group2,group3"。(和静态token类似,只不过文件里面存放着密码)

OpenID 

OAuth 2.0的认证机制

ServiceAccount

ServiceAccount是 Kubernetes 自动生成的,并会自动挂载到容器的/run/secrets/kubernetes.io/serviceaccount 目录中。

当你去建立任何的namespace的时候,k8s就有一个控制器,它看见namespace创建了,它就会去建立sa,它会生成token,这个token签发的内容其实就是代表了这个token签发给哪个namespace的,哪个serviceaccount的,这个token是apiserver签发的,所以你带着token去访问apiserver的时候,它就知道这个token合法还是非法,代表的是哪个namespace,哪个serviceaccount。

静态token 示例

 在这个scv文件里面创建了用户,token叫做cncamp-token,这个是用户的token。用户名是cncamp,它的uid是1000,然后它发到3个group里面,这就是简单的token文件。

如果我们要去启用静态的token,那么我要去修改apiserver的配置文件,这个就是告诉apiserver说,这个文件里面的内容我是承认的。也即是将主机的文件mount到apiserver的pod里面。

Kubernetes API Server 的认证机制_第1张图片

Kubernetes API Server 的认证机制_第2张图片

在这个pod的volumes里面定义了一个hostpath的volume

Kubernetes API Server 的认证机制_第3张图片

更新完apiserver的yaml文件会去做个重启,如果get pod成功那么说明api-server重启成功。

这里面加了header,这个header加了token,这个token代表了cncamp这个用户,直接发rest

api调用通过curl命令。

Kubernetes API Server 的认证机制_第4张图片

可以看到由于权限的问题,它的code是403是鉴权不过的,其实认证是通过的,因为它知道你的token对应的用户是cncamp。

也就是说带着cncamp的token去访问apiserver,它已经去本地的static token file里面去校验token代表哪个用户了,它查找到了这个用户并且说这个用户没有权限,其实整个的认证就已经过了。

x509证书

kubeadm搭建的集群,本身就使用了x509证书

Kubernetes API Server 的认证机制_第5张图片

serviceaccount

当创建任何的serviceaccount的时候,在这个namespace里面,其实k8s会自动的在这个namspace里面创建一个叫default的serviceaccount,所谓的serviceaccount就是系统账号。

Kubernetes API Server 的认证机制_第6张图片 每个系统账号会有对应的secret,可以看到有ca文件,还有namespace,这个是base64加密了的,还有一个token,这个其实就是apiserver签发的jwt token,和之前静态token是类似的。

Kubernetes API Server 的认证机制_第7张图片

Kubernetes API Server 的认证机制_第8张图片

可以看到只要带着这个token去访问apiserver,apiserver就能够认出我是谁,配合权限控制那么就可以根据这个token去访问apiserver里面的任何对象。

如果基于内置的认证方式还不能满足你需求,公司有自己的认证系统,认证方式都在集群之外,那么怎么使得k8s集群和这些认证平台去集成,那么就需要通过webhook,k8s认证也支持webhook。

你可以基于webhook来配置来指向外部的认证服务器,有了这种认证集成的方式之后,那么k8s就可以和任何平台去做集成。

Webhook 令牌身份认证

  • --authentication-token-webhook-config-file 指向一个配置文件,其中描述如何访问远程的Webhook服务。
  • --authentication-token-webhook-cache-ttl用来设定身份认证决定的缓存时间。默认时长为2分钟。

匿名请求

  • 如果使用AlwaysAllow 以外的认证模式,则匿名请求默认开启,但可用--anonymouSs-auth=false禁止匿名请求。

你可能感兴趣的:(Kubernetes,APIServer,kubernetes)