kubernetes1.5新特性：kubelet API增加认证和授权能力

奥德赛F9

一、背景介绍
　　在Kubernetes1.5中，对于kubelet新增加了几个同认证/授权相关的几个启动参数，分别是：
　　认证相关参数：
　　·       anonymous-auth参数：是否启用匿名访问，可以选择true或者false，默认是true，表示启用匿名访问。
　　·       authentication-token-webhook参数：使用tokenreviewAPI来进行令牌认证。
　　·       authentication-token-webhook-cache-ttl参数：webhook令牌认证缓存响应时长。
　　·       client-ca-file参数：表示使用x509证书认证，如果设置此参数，那么就查找client-ca-file参数设置的认证文件，任何请求只有在认证文件中存在的对应的认证，那么才可以正常访问。
　　授权相关参数：
　　·       authorization-mode参数：kubelet的授权模式，可以选择AlwaysAllow或者Webhook，如果设置成Webhook，那么使用SubjectAccessReviewAPI进行授权。
　　·       authorization-webhook-cache-authorized-ttl参数：webhook授权时，已经被授权内容的缓存时长。
　　·       authorization-webhook-cache-unauthorized-ttl参数：webhook授权时，没有被授权内容的缓存时长。

二、认证
　　默认anonymous-auth参数设置成true，也就是可以进行匿名认证，这时对kubelet API的请求都以匿名方式进行，系统会使用默认匿名用户和默认用户组来进行访问，默认用户名“system:anonymous”，默认用户组名“system:unauthenticated”。
　　可以禁止匿名请求，这时就需要设置kubelet启动参数：“--anonymous-auth=false”，这时如果请求时未经过认证的，那么会返回“401 Unauthorized”。
　　可以使用x509证书认证（X.509格式的证书是最通用的一种签名证书格式）。这时就需要设置kubelet启动参数：“--client-ca-file”，提供认证文件，通过认证文件来进行认证。同时还需要设置api server组件启动参数：“--kubelet-client-certificate”和“--kubelet-client-key”。在认证文件中一个用户可以属于多个用户组，比如下面例子产生的认证：
　　openssl req -new -key jbeda.pem -outjbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app2"
　　这个例子创建了csr认证文件，这个csr认证文件作用于用户jbeda，这个用户属于两个用户组，分别是app1和app2。
　　可以启用令牌认证，这时需要通过命令“--runtime-config=authentication.k8s.io/v1beta1=true“启用api server组件authentication.k8s.io/v1beta1相关的API，还需要启用kubelet组件的“--authentication-token-webhook”、“--kubeconfig”、“--require-kubeconfig”三个参数。
　　kubeconfig参数：设置kubelet配置文件路径，这个配置文件用来告诉kubelet组件api server组件的位置，默认路径是。
　　require-kubeconfig参数：这是一个布尔类型参数，可以设置成true或者false，如果设置成true，那么表示启用kubeconfig参数，从kubeconfig参数设置的配置文件中查找api server组件，如果设置成false，那么表示使用kubelet另外一个参数“api-servers”来查找api server组件位置。
　　在kubernetes源代码中，有一个错误的注释：
　　

func NewKubeletServer() *KubeletServer {　　

　　versioned:= &v1alpha1.KubeletConfiguration{}
　　

　　api.Scheme.Default(versioned)
　　

　　config:= componentconfig.KubeletConfiguration{}
　　

　　api.Scheme.Convert(versioned,&config, nil)
　　

　　return&KubeletServer{
　　

　　KubeConfig:           flag.NewStringFlag("/var/lib/kubelet/kubeconfig"),
　　

　　RequireKubeConfig:    false, // in 1.5, default to true
　　

　　KubeletConfiguration:config,
　　

　　}
　　

　　
}
　　

　　这里面对RequireKubeConfig参数默认值的设置是false，但是在注释中写的确实true。
　　启用令牌认证后，kubelet会调用TokenReview API来进行令牌认证。
　　下面是一个kubeconfig文件格式样例：
　　

clusters:　　

　　-name: name-of-remote-authn-service
　　

　　cluster:
　　

　　certificate-authority: /path/to/ca.pem         # 校验远程服务的认证文件
　　

　　server: https://authn.example.com/authenticate # 远程服务访问https路径
　　

　　

　　
users:
　　

　　-name: name-of-api-server
　　

　　user:
　　

　　client-certificate: /path/to/cert.pem    # webhook插件使用的认证文件
　　

　　client-key: /path/to/key.pem         # 认证文件对应的密钥文件
　　

　　

　　
current-context: webhook
　　

　　
contexts:
　　

　　
- context:
　　

　　cluster: name-of-remote-authn-service
　　

　　user: name-of-api-sever
　　

　　name: webhook
　　认证请求格式样例如下：
　　

{　　

　　"apiVersion": "authentication.k8s.io/v1beta1",
　　

　　"kind": "TokenReview",
　　

　　"spec": {
　　

　　"token": "(BEARERTOKEN)"
　　

　　}
　　

　　
}
　　

　　成功的认证响应如下：
　　

{　　

　　"apiVersion": "authentication.k8s.io/v1beta1",
　　

　　"kind": "TokenReview",
　　

　　"status": {
　　

　　"authenticated": true,
　　

　　"user": {
　　

　　"username": "janedoe@example.com",
　　

　　"uid": "42",
　　

　　"groups": [
　　

　　"developers",
　　

　　"qa"
　　

　　],
　　

　　"extra": {
　　

　　"extrafield1": [
　　

　　"extravalue1",
　　

　　"extravalue2"
　　

　　]
　　

　　}
　　

　　}
　　

　　}
　　

　　
}
　　

　　失败的认证响应如下：
　　

{　　

　　"apiVersion": "authentication.k8s.io/v1beta1",
　　

　　"kind": "TokenReview",
　　

　　"status": {
　　

　　"authenticated": false
　　

　　}
　　

　　
}
　　

三、授权
　　任何请求被成功认证后才会被授权，包括匿名认证请求。默认的授权模式是AlwaysAllow，意味着允许任何请求。其实对于API的请求是需要进行更细粒度划分和授权的，有下面两点原因：
　　虽然允许匿名用户请求，但是应该限制匿名用户可以访问的API。
　　虽然允许认证用户请求，但是不同认证用户应该可以访问不同的API，而不能所有认证用户只能访问相同的API。
　　要想进行API权限控制，需要通过命令“--runtime-config= authorization.k8s.io /v1beta1=true“启用api server组件authorization.k8s.io/v1beta1相关的API，还需要将授权模式参数“--authorization-mode”设置成Webhook，然后启用kubelet组件的“--kubeconfig”和“--require-kubeconfig”两个参数，这两个参数的作用在上面认证章节已经详细介绍过了，这里不再介绍。
　　Kubelet接着就会调用api server组件的SubjectAccessReviewAPI来判断哪个请求需要进行授权控制。
　　请求动作类型是根据HTTP访问类型进行划分的，如下面表格所示：
　　HTTP verb
　　request verb
　　POST
　　create
　　GET, HEAD
　　get
　　PUT
　　update
　　PATCH
　　patch
　　DELETE
　　delete
　　资源访问请求是根据不同请求路径来进行划分的，如下面表格所示：
　　Kubelet API
　　资源名称
　　子资源名称
　　/stats/*
　　nodes
　　stats
　　/metrics/*
　　nodes
　　metrics
　　/logs/*
　　nodes
　　log
　　/spec/*
　　nodes
　　spec
　　all others
　　nodes
　　proxy
　　对于资源访问请求，访问时名字空间和API组这两个属性永远都是空值，资源名称的属性值就是kubelet所在节点对象名称。
　　要是想让kubelete API可以进行权限控制，还需要确保api server组件已经启用了“--kubelet-client-certificate”和“--kubelet-client-key”连个参数，
　　kubelet-client-certificate参数：客户端认证文件路径
　　kubelet-client-key参数：客户端密钥文件路径
　　还确保客户端被授权可以访问下面属性：
　　·        verb=*, resource=nodes,subresource=proxy
　　·        verb=*, resource=nodes, subresource=stats
　　·        verb=*, resource=nodes,subresource=log
　　·        verb=*, resource=nodes,subresource=spec
　　·        verb=*, resource=nodes,subresource=metrics

总结
　　Kubernetes1.5中增加了kubele API的认证和授权功能，从中可以发现社区对K8S在生产环节中安全性的设计日趋完善，也说明有越来越多的客户在生产环境中使用K8S了。经常访问K8S社区就会发现，在基础功能日趋完善的情况下，K8S社区现在对于跨云（Federation）和安全认证（Security/Auth）这两方面有了长足的进步，将来的K8S会适合更多的生产环境，会成为一款特别受欢迎的容器编排开源软件产品。