kubernetes API 访问控制在阿里云容器服务(ACK)上的实践

提起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的细节上，极大的下降了使用门槛

原文连接 本文为云栖社区原创内容，未经容许不得转载。