提起K8s API的访问控制,很多同学应该都会想到RBAC,这是K8s用来做权限控制的方法,但是K8s对API的访问控制却不止于此,今天我们就来简单介绍下K8s的访问控制以及ACK如何利用这套方法提供便捷的访问控制管理
访问控制简要说明
控制流程如上图所示,我们今天关注点在前两步,也就是图中的Authentication
和Authorization
Authentication
做的是身份校验,Authentication
支持的方法包括X509 Client Certs、Password、Plain Tokens、Bootstrap Tokens 和 JWT Tokens,今天我们要实践的就是X509 Client Certs校验方式
API server启动时传入--client-ca-file=SOMEFILE
即可启用证书校验,参数指定的文件中必须包含至少一个CA证书用于校验传入的客户端证书。
验证通过后,证书中的common name
(CN)字段会作为请求的username,organization
(O)字段作为请求的group
Authorization
做的是授权鉴定,一个请求通过Authentication
后,会带着一个user和group,Authorization
做的就是判断请求的方法(verb)和对象(object)是否在user和group的权限范围内;从1.8版本之后,RBAC模式进入stable状态,也是ACK默认启用的鉴权方式,RBAC模块会通过role/clusterrole和rolebinding/clusterrolebinding来鉴定请求所关联的user和group是否有操作的权限
下面我们通过操作来看下ACK上是如何做这些事的
环境准备
kubernetes
可以通过容器服务管理控制台非常方便地快速创建 Kubernetes 集群。具体过程可以参考这里
一个授予集群权限的子账号
子账号绑定的操作请参考这里
验证
我们按照上面的步骤操作,给子账号绑定default空间下的开发人员
角色
登录子账号,在集群
的详情页找到kubeconfig的信息,复制其中的user.client-certificate-data
字段,执行下面的命令
echo $CERTIFICATE | base64 -D > test.crt
openssl x509 -in test.crt -noout -text
会看到类似下面的输出
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 980377 (0xef599)
Signature Algorithm: sha256WithRSAEncryption
Issuer: O=cb4541f68933d4927b445b1eec47ce8b6, OU=default, CN=cb4541f68933d4927b445b1eec47ce8b6
Validity
Not Before: Apr 24 08:19:00 2019 GMT
Not After : Apr 23 08:24:49 2022 GMT
Subject: O=system:users, OU=, CN=232157355171679750
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
...
看证书的subject字段,O=system:users CN=232157355171679750
,表示使用这个证书作为身份校验的请求,在服务端看来,user是232157355171679750,group是system:users
接下来我们继续看这个user和group在集群中被赋予的权限
~ kubectl get rolebinding
NAME AGE
232157355171679750-default-rolebinding 10s
~ kubectl get rolebinding 232157355171679750-default-rolebinding -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
...
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cs:ns:dev
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: "232157355171679750"
可以看到user 232157355171679750被绑定了cs:ns:dev
这个集群角色,可以操作许多资源,但是都被限制在default这个namespace下(不能查看node,因为node是跨namespace的资源),因为给这个user绑定是通过rolebinding来做的,是受namespace的约束的(kubectl describe clusterrole cs:ns:dev即可看到这个子账号被授予的所有权限)
我们再给账号扩大一些权限,这次给他绑定整个集群的管理员
角色
然后我们就会发现刚才的rolebinding已经被删除了
~ kubectl get rolebinding
No resources found.
因为这次绑定是整个集群范围内的,所以产生的是clusterrolebinding
~ kubectl get clusterrolebinding
NAME AGE
232157355171679750-clusterrolebinding 3s
可以用上面的方法继续查看集群管理员
角色下的所有权限
但是集群管理员并不是权限最高的角色,权限最高的角色是自定义列表中的cluster-admin
,这是kubernetes集群启动后内置的角色,也是主账号创建集群后生成的config文件中绑定的角色
角色和权限的选择
既然kubernetes中内置了许多的role和clusterrole,那我们该如何选择呢?又如何判断当前的角色是否满足了需求呢?
还好kubectl已经提供了对应的命令来帮助我们快速判断权限是否充分
kubectl auth can-i <verb> <resource> [<resourceName>]
我们还是以一个被绑定了集群管理员
的角色为例,下面的kubectl命令均是使用了对应的config文件
~ kubectl auth can-i delete no
yes
~ kubectl auth can-i drain no
no - no RBAC policy matched
~ kubectl auth can-i taint no
no - no RBAC policy matched
~ kubectl auth can-i cordon no
no - no RBAC policy matched
~ kubectl auth can-i label no
no - no RBAC policy matched
~ kubectl auth can-i delete pv
yes
~ kubectl auth can-i delete pvc
yes
我们看到这个角色的可以删除node
、pv
和pvc
,但是不能对node
做drain
,taint
,cordon
,label
,可以利用这个工具快速定位操作失败是否和权限有关
总结
ACK将阿里云上的子账号系统和kubernetes本身的访问控制非常平滑的连接在一起,对用户非常友好,不需要花太多的精力在RBAC的细节上,极大的降低了使用门槛