17.实践篇：Kubernetes的安全三板斧之apiserver和RBAC
17.实践篇：Kubernetes的安全三板斧之apiserver和RBAC
1.如何保证Kubernetes系统安全
如何保证Kubernetes系统安全，我们可以从以下三大部分进行学习、研究和设计：
1.1.Apiserver
首当其冲的就是apiserver，他是系统安全三板斧中的第一道关卡，其作用为：
who？谁能进入我们的kubernetes集群，这个谁可以是客户端用户、应用程序，也可以是集群中的node节点。
说到这里，你可能对后半句话有些疑虑。
防范外部的访问我是知道的，为什么还要防范集群内部的请求呢？
容我先来举个栗子。
如果你了解、运维过spring cloud，那你应该会碰到这个难题：
每个环境我们都有注册中心eureka，那我们如何保障应用不会出现乱注册的情况呢？
比如：生产环境的应用注册到测试环境的eureka?测试环境的应用注册到生产环境的eureka？
无论哪个情况发生，都是很致命的！
也许你会考虑，借助一系列配置管理的规范或者ITIL流程，又或者基于人员角色的分而治之来规避这个情况的发生，但这都是治标不治本的！
重点在于缺少双向认证的功能！换句话来说就是：谁能注册到我这里来，我是要有验证的，而不是随便让你可以进行服务的注册。
这个双向认证的思想，在kubernetes中尤为重要，不是所有知道我们集群主节点信息或者join信息的节点都可以肆意加入集群，这是很有风险的。
kubernetes的bootstrap token引导令牌（会在后面章节讲解）就此诞生！他会向已知可信任的node节点颁发一个引导令牌，其中会有一个失效期，可能是12小时，也可能是1天，这取决于集群管理员的配置。
他会告诉node节点，你必须要在这段时间内加入集群，否则我就不信任你了，你也就不能再加入集群了。
同时apiserver也通过各种https证书，保证了集群内外部的数据交互的安全。
1.2.RBAC
接着就是系统安全三板斧中的第2道关卡：RBAC！基于角色的访问控制（Role-Based Access Control, 即”RBAC”）使用”rbac.authorization.k8s.io” API Group实现授权决策，允许管理员通过Kubernetes API动态配置策略，其职责为：
what？对于已知的客户端用户，他们需要什么的权限，他们能够操作什么类型的资源，这就是他所负责的事情了。
RBAC的配置顺序如下所示：
首先，定义一个服务账号service account，也就是定义角色；
接着，定义一个role策略，比如：允许查看pod，禁止describepod等；
最后，将定义好的角色和role策略进行绑定(binding)即可。
RBAC中配置生效的经验之谈：
role+rolebinding=作用于对应名称空间的策略
clusterrole+clusterrolebinding=作用域集群级别的策略
clusterrole+rolebinding=作用于对应名称空间的策略，作用同第一条。其好处是更灵活更简洁。
如果你配置过jumpserver的用户组、机器组和授权，想必很好理解。
1.3.Admission Controller
最后，把手整个系统安全的就是Admission Controller准入控制器了。对于已知用户，他可以管理（可能是查看、也可能是新建、也可能会删除等等）其命名空间或者对应集群下的所有授权资源。但这里有一个问题！不知道，你想到了没有？
如何去校验用户的操作是否合规呢？
例如：是否在yaml中配置了limits和requets字段，又或者研发人员配置的这两个字段是否合理？
这也是十分重要的一个环节，对于初创公司或者是kubernetes初建设团队，这个环节可能也可容许暂时被忽略，大家基于一定的自觉、团队研发和上线流程的规范，来软限制这点。但当你的团队、集群越来越大的时候，Admission Controller准入控制器的上线和把控是缺一不可的！
Admission Controller准入控制器我会在后面的章节着重细讲，这里不再展开。
2.实战：Apiserver
1) 首先，我们生成一个用户验证的用户私钥ilinux.crt
openssl genrsa -out ilinux.crt 2048
2) 接着，生成证书签名请求文件ilinux.csr，用户证书签名
openssl req -new -key ilinux.key -out ilinux.csr -subj "/CN=ilinux/O=kubeusers"
3) 然后，使用k8s的ca.crt和ca.key进行签名生成证书ilinux.crt，有效期为365天
[root@centos-1 pki]# cd /etc/kubernetes/pki/ [root@centos-1 pki]# openssl x509 -req -in ilinux.csr -CA ./ca.crt -CAkey ./ca.key -CAcreateserial -out ilinux.crt -days 365 Signature ok subject=/CN=ilinux/O=kubeusers Getting CA Private Key
4) 设置新集群（mykube），指明apiserver地址、k8s证书路径和隐藏证书，并保存在（/tmp/ilinux.kubeconfig）
kubectl config set-cluster mykube --server="https://192.168.0.104:6443" --certificate-authority=/etc/kubernetes/pki/ca.crt --embed-certs=true --kubeconfig=/tmp/ilinux.kubeconfig
5) 此时，通过查看集群，可以发现新集群已经创建成功；名为mykube
[root@centos-1 ~]# kubectl config get-clusters NAME mykube kubernetes
6) 接着，我们需要配置新集群权限，其自定义权限名为ilinux，username需要和ilinux.csr的CN需要保持一致，--embed-certs=true表示需要打包存放
kubectl config set-credentials ilinux --client-certificate=/etc/kubernetes/pki/ilinux.crt --client-key=/etc/kubernetes/pki/ilinux.key --username=ilinux --embed-certs=true --kubeconfig=/tmp/ilinux.kubeconfig
7) 配置context上下文，并绑定上面设置的新集群名、用户名和自定义权限名，并保存在/tmp/ilinux.kubeconfig
kubectl config set-context ilinux@mykube --cluster=mykube --user=ilinux --kubeconfig=/tmp/ilinux.kubeconfig
8) 查询当前集群配置信息，发现新集群已经载入，但没有载入使用。
当前读取的配置是current-context: kubernetes-admin@kubernetes
[root@centos-1 ~]# kubectl config view
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://192.168.0.104:6443
name: kubernetes
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://192.168.0.104:6443
name: mykube
contexts:
- context:
cluster: mykube
user: ilinux
name: ilinux@mykube
- context:
cluster: kubernetes
user: kubernetes-admin
name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: ilinux
user:
client-certificate-data: REDACTED
client-key-data: REDACTED
username: ilinux
- name: kubernetes-admin
user:
client-certificate-data: REDACTED
client-key-data: REDACTED
9) 这里，我们使用新配置的use-context ilinux@mykube进行操作，发现已经没有查询pod的权限了
[root@centos-1 tmp]# kubectl get pods NAME READY STATUS RESTARTS AGE ngx-new-cb79d555-hfc7h 1/1 Running 0 9d [root@centos-1 tmp]# kubectl config use-context ilinux@mykube Switched to context "ilinux@mykube". [root@centos-1 tmp]# kubectl get pods Error from server (Forbidden): pods is forbidden: User "ilinux" cannot list resource "pods" in API group "" in the namespace "default"
10) 这时候，再切换成管理员账号，发现一切正常
[root@centos-1 tmp]# kubectl config use-context kubernetes-admin@kubernetes Switched to context "kubernetes-admin@kubernetes". [root@centos-1 tmp]# kubectl get pods NAME READY STATUS RESTARTS AGE ngx-new-cb79d555-hfc7h 1/1 Running 0 9d
11) 我们还可以使用位置参数的方式，使用自定义配置文件进行用户权限临时的切换
[root@centos-1 tmp]# kubectl config view --kubeconfig=/tmp/ilinux.kubeconfig
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://192.168.0.104:6443
name: mykube
contexts:
- context:
cluster: mykube
user: ilinux
name: ilinux@mykube
current-context: ""
kind: Config
preferences: {}
users:
- name: ilinux
user:
client-certificate-data: REDACTED
client-key-data: REDACTED
username: ilinux
[root@centos-1 tmp]# kubectl config use-context ilinux@mykube --kubeconfig=/tmp/ilinux.kubeconfig
Switched to context "ilinux@mykube".
[root@centos-1 tmp]# kubectl get pods --kubeconfig=/tmp/ilinux.kubeconfig
Error from server (Forbidden): pods is forbidden: User "ilinux" cannot list resource "pods" in API group "" in the namespace "default"
[root@centos-1 tmp]# kubectl get pods
NAME READY STATUS RESTARTS AGE
ngx-new-cb79d555-hfc7h 1/1 Running 0 9d
3.RBAC介绍
RBAC的介绍，上面已经聊来不少，如果你还感兴趣，可以参考RBAC官方文档。
3.1.授权模型
基于节点：
Node：专用的授权插件，根据Pod对象调度的结果为Node进行授权
基于用户：
ABAC：1.17之前的策略，新版本已经默认使用RBAC
RBAC：赋予某个角色对于某个资源进行某种操作，其中角色可以是人也可以是组
其他：
Webhook
3.2.集群策略查看
你可以在集群中，使用cat /etc/kubernetes/manifests/kube-apiserver.yaml查看到当前集群生效的策略是什么？
--authorization-mode=Node,RBAC看到没有？
[root@centos-1 dingqishi]# cat /etc/kubernetes/manifests/kube-apiserver.yaml apiVersion: v1 kind: Pod metadata: creationTimestamp: null labels: component: kube-apiserver tier: control-plane name: kube-apiserver namespace: kube-system spec: containers: - command: - kube-apiserver - --advertise-address=192.168.0.104 - --allow-privileged=true - --authorization-mode=Node,RBAC
3.3.相关命令
名称空间级别权限和绑定的配置查看：
kubectl explain role
kubectl explain rolebinding
集群级别权限和绑定的配置查看：
kubectl explain ClusterRole
kubectl explain ClusterRoleBinding
已有策略的详情查看：
kubectl get role view -o yaml
kubectl get clusterrole view -o yaml
4.实战：RBAC
（以下所有操作都基于上面创建的ilinux用户进行，并且每个操作之前需要删除之前配置过的权限，否则会相互影响）
4.1.Role+RoleBinding
应用场景：某个名称空间级别的权限授权
我们先编辑role：res-reader.yaml，定义规则为：default名称空间下，只能get、list和watch相关资源
kind: Role #名称空间权限 apiVersion: rbac.authorization.k8s.io/v1 metadata: namespace: default #只能读取default名称空间下的对应规则 name: res-reader rules: - apiGroups: [""] # "" 表示核心群组：core API group resources: ["pods", "pods/log", "services"] verbs: ["get", "list", "watch"]
然后我们来定义授权绑定rolebinding：ilinux-res-reader.yaml，其作用是将ilinux用户，绑定到我们上面定义的名为res-reader的权限上。
kind: RoleBinding #名称空间级别权限绑定;ClusterRoleBinding为集群级别的权限绑定 apiVersion: rbac.authorization.k8s.io/v1 metadata: name: ilinux-res-reader #增加可读性，命名规则：<用户>-<权限> namespace: default subjects: - kind: User name: ilinux apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: res-reader apiGroup: rbac.authorization.k8s.io
依次apply配置文件，发现ilinux用户在default名称空间下有对应pods, pods/log, services的对应权限，和预期一样
[root@centos-1 RBAC]# kubectl get pod --kubeconfig=/tmp/ilinux.kubeconfig NAME READY STATUS RESTARTS AGE ngx-new-cb79d555-hfc7h 1/1 Running 0 10d [root@centos-1 RBAC]# kubectl get service --kubeconfig=/tmp/ilinux.kubeconfig NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 11d [root@centos-1 RBAC]# kubectl get service --kubeconfig=/tmp/ilinux.kubeconfig -n ingress-nginx Error from server (Forbidden): services is forbidden: User "ilinux" cannot list resource "services" in API group "" in the namespace "ingress-nginx"
4.2.ClusterRole+ClusterRoleBinding
应用场景：k8s集群级别的权限授权
编辑ClusterRole：cluster-res-reader.yaml
kind: ClusterRole #集群范围权限 apiVersion: rbac.authorization.k8s.io/v1 metadata: name: cluster-res-reader rules: - apiGroups: [""] # "" 表示核心群组：core API group resources: ["pods", "pods/log", "services"] verbs: ["get", "list", "watch"]
编辑ClusterRoleBinding：cluster-ilinux-res-reader.yaml
kind: ClusterRoleBinding #ClusterRoleBinding为集群级别的权限绑定 apiVersion: rbac.authorization.k8s.io/v1 metadata: name: cluster-ilinux-res-reader #增加可读性，命名规则：<用户>-<权限> subjects: - kind: User name: ilinux apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: cluster-res-reader apiGroup: rbac.authorization.k8s.io
依次apply配置文件，并通过以下命令观察权限生成情况
[root@centos-1 RBAC]# kubectl get clusterrole [root@centos-1 RBAC]# kubectl get clusterrolebinding
这时，我们发现ilinux用户已经具有集群级别（所有名称空间）的对应权限
[root@centos-1 RBAC]# kubectl get service --kubeconfig=/tmp/ilinux.kubeconfig -n ingress-nginx NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx-ingress-controller NodePort 10.99.160.254 <none> 80:30080/TCP,443:30443/TCP 26h [root@centos-1 RBAC]# kubectl get service --kubeconfig=/tmp/ilinux.kubeconfig NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 11d
4.3.ClusterRole+RoleBinding
应用场景：交叉使用，其中ClusterRole策略会降级成rolebinding名称空间级别的策略，效果和role+rolebinding一样
好处：在名称空间很多的时候，重复权限的配置文件会少一半，而且更灵活
使用上面的ClusterRole（cluster-res-reader.yaml），并apply-f
编辑rolebinding：cluster-default-ilinux-res-reader.yaml
kind: RoleBinding #名称空间级别权限绑定;ClusterRoleBinding为集群级别的权限绑定 apiVersion: rbac.authorization.k8s.io/v1 metadata: name: cluster-default-ilinux-res-reader #增加可读性，命名规则：<用户>-<权限> namespace: default subjects: - kind: User name: ilinux apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: cluster-res-reader apiGroup: rbac.authorization.k8s.io
测试和预期一样，ClusterRole降级成default名称空间的权限了
[root@centos-1 RBAC]# kubectl get service --kubeconfig=/tmp/ilinux.kubeconfig NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 11d [root@centos-1 RBAC]# kubectl get service --kubeconfig=/tmp/ilinux.kubeconfig -n ingress-nginx Error from server (Forbidden): services is forbidden: User "ilinux" cannot list resource "services" in API group "" in the namespace "ingress-nginx"
@版权声明：51CTO独家出品，未经允许不能转载，否则追究法律责任