K8S安全实战篇之RBAC认证授权-v1
k8s安全管理:认证、授权、准入控制概述
认证
- 认证基本介绍:kubernetes主要通过APIserver对外提供服务,那么就需要对访问apiserver的用户做认证,如果任何人都能访问apiserver,那么就可以随意在k8s集群部署资源,这是非常危险的,也容易被黑客攻击渗透,所以需要我们对访问k8s系统的apiserver的用户进行认证,确保是合法的符合要求的用户。
- 授权基本介绍:认证通过后仅代表它是一个被apiserver信任的用户,能访问apiserver,但是用户是否拥有删除资源的权限, 需要进行授权操作,常见的授权方式有rbac授权。
- 准入控制基本介绍:当用户经过认证和授权之后,最后一步就是准入控制了,k8s提供了多种准入控制机制,它有点类似"插件",为apiserver提供了很好的"可扩展性"。请求apiserver时,通过认证、鉴权后、持久化("api对象"保存到etcd)前,会经过"准入控制器",让它可以做"变更和验证"
为什么需要准入控制器:如果我们创建pod时定义了资源上下限,但不满足LimitRange规则中定义的资源上下限,此时LimitRanger就会拒绝我们创建此pod
假如我们定义了一个名称空间叫做test-aa,这个名称空间做下资源限制:限制最多可以使用10vCPU、10Gi内存,在这个名称空间test-aa下创建的所有pod,定义limit的时候,所有pod的limit值不能超过test-aa这个名称空间设置的limit上线。
k8s客户端访问apiserver的几种认证方式
客户端认证:
客户端认证也称为双向TLS认证, kubectl在访问apiserver的时候,apiserver也要认证kubectl是否是合法的,他们都会通过ca根证书来进行验证,如下图:
Bearertoken
Bearertoken的方式,可以理解为apiserver将一个密码通过了非对称加密的方式告诉了kubectl,然后通过该密码进行相互访问,如下图:
Kubectl访问k8s集群,要找一个kubeconfig文件,基于kubeconfig文件里的用户访问apiserver
Serviceaccount
上面客户端证书认证和Bearertoken的两种认证方式,都是外部访问apiserver的时候使用的方式,那么我们这次说的Serviceaccount是内部访问pod和apiserver交互时候采用的一种方式。Serviceaccount包括了,namespace、token、ca,且通过目录挂载的方式给予pod,当pod运行起来的时候,就会读取到这些信息,从而使用该方式和apiserver进行通信。如下图:
kubeconfig文件
官方地址:
https://kubernetes.io/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig/
在K8S集群当中,当我们使用kubectl操作k8s资源时候,需要确定我们用哪个用户访问哪个k8s集群,kubectl操作k8s集群资源会去/root/.kube目录下找config文件,可以通过kubectl config查看config文件配置,如下:
python
kubectl config view
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://192.168.40.180:6443 #apiserver的地址
name: kubernetes #集群的名字
contexts:
- context:
cluster: kubernetes
user: kubernetes-admin
name: kubernetes-admin@kubernetes #上下文的名字
current-context: kubernetes-admin@kubernetes #当前上下文的名字
kind: Config
preferences: {}
users:
- name: kubernetes-admin
user:
client-certificate-data: REDACTED
client-key-data: REDACTED
在上面的配置文件当中,定义了集群、上下文以及用户。其中Config也是K8S的标准资源之一,在该配置文件当中定义了一个集群列表,指定的集群可以有多个;用户列表也可以有多个,指明集群中的用户;而在上下文列表当中,是进行定义可以使用哪个用户对哪个集群进行访问,以及当前使用的上下文是什么。
python
kubectl get pods --kubeconfig=/root/.kube/config
授权
用户通过认证之后,什么权限都没有,需要一些后续的授权操作,如对资源的增删该查等,kubernetes1.6之后开始有RBAC(基于角色的访问控制机制)授权检查机制。
Kubernetes的授权是基于插件形成的,其常用的授权插件有以下几种:
- Node(节点认证)
- ABAC(基于属性的访问控制)
- RBAC(基于角色的访问控制)
- Webhook(基于http回调机制的访问控制)
什么是RBAC(基于角色的授权)
让一个用户(Users)扮演一个角色(Role),角色拥有权限,从而让用户拥有这样的权限,随后在授权机制当中,只需要将权限授予某个角色,此时用户将获取对应角色的权限,从而实现角色的访问控制。如图:
在k8s的授权机制当中,采用RBAC的方式进行授权,其工作逻辑是,把对对象的操作权限定义到一个角色当中,再将用户绑定到该角色,从而使用户得到对应角色的权限。如果通过rolebinding绑定role,只能对rolebingding所在的名称空间的资源有权限,上图user1这个用户绑定到role1上,只对role1这个名称空间的资源有权限,对其他名称空间资源没有权限,属于名称空间级别的;
另外,k8s为此还有一种集群级别的授权机制,就是定义一个集群角色(ClusterRole),对集群内的所有资源都有可操作的权限,从而将User2通过ClusterRoleBinding到ClusterRole,从而使User2拥有集群的操作权限。
Role、RoleBinding、ClusterRole和ClusterRoleBinding的关系
用户基于rolebinding绑定到role
限定在rolebinding所在的名称空间
用户基于rolebinding绑定到clusterrole
上面我们说了两个角色绑定:
(1)用户通过rolebinding绑定role
(2)用户通过rolebinding绑定clusterrole
rolebinding绑定clusterrole的优点:
假如有6个名称空间,每个名称空间的用户都需要对自己的名称空间有管理员权限,那么需要定义6个role和rolebinding,然后依次绑定,如果名称空间更多,我们需要定义更多的role,这个是很麻烦的,所以我们引入clusterrole,定义一个clusterrole,对clusterrole授予所有权限,然后用户通过rolebinding绑定到clusterrole,就会拥有自己名称空间的管理员权限了
注:RoleBinding仅仅对当前名称空间有对应的权限。
用户基于clusterrolebinding绑定到clusterrole
用户基于rbac授权有几种方案:
- 基于rolebinding绑定到role上
- 基于rolebinding绑定到clusterrole上
- 基于clusterrolebinding绑定到clusterrole上
准入控制
在k8s上准入控制器的模块有很多,其中比较常用的有LimitRanger、ResourceQuota、ServiceAccount、PodSecurityPolicy(k8s1.25废弃了)等等,对于前面三种准入控制器系统默认是启用的,我们只需要定义对应的规则即可;对于PodSecurityPolicy(k8s1.25废弃了)这种准入控制器,系统默认没有启用,如果我们要使用,就必需启用以后,对应规则才会正常生效;这里需要注意一点,对应psp准入控制器,一定要先写好对应的规则,把规则和权限绑定好以后,在启用对应的准入控制器,否则先启用准入控制器,没有对应的规则,默认情况它是拒绝操作,这可能导致现有的k8s系统跑的系统级pod无法正常工作;所以对于psp准入控制器要慎用,如果规则和权限做的足够精细,它会给我们的k8s系统安全带来大幅度的提升,反之,可能导致整个k8s系统不可用。
查看apiserver启用的准入控制器有哪些
python
cat /etc/kubernetes/manifests/kube-apiserver.yaml
apiVersion: v1
kind: Pod
metadata:
annotations:
kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: 192.168.40.63:6443
creationTimestamp: null
labels:
component: kube-apiserver
tier: control-plane
name: kube-apiserver
namespace: kube-system
spec:
containers:
- command:
- kube-apiserver
- --advertise-address=192.168.40.180
...
- --enable-admission-plugins=NodeRestriction
apiserver启用准入控制插件需要使用--enable-admission-plugins选项来指定,该选项可以使用多个值,用逗号隔开表示启用指定的准入控制插件;这里配置文件中显式启用了NodeRestrication这个插件;默认没有写在这上面的内置准入控制器,它也是启用了的,比如LimitRanger、ResourceQuota、ServiceAccount等等;对于不同的k8s版本,内置的准入控制器和启用与否请查看相关版本的官方文档;对于那些没有启动的准入控制器,我们可以在上面选项中直接启用,分别用逗号隔开即可。
Useraccount和ServiceAccount介绍
kubernetes中账户分为:UserAccounts(用户账户) 和 ServiceAccounts(服务账户) 两种:
- UserAccount是给kubernetes集群外部用户使用的,如kubectl访问k8s集群要用useraccount用户, kubeadm安装的k8s,默认的useraccount用户是kubernetes-admin;
- k8s客户端(一般用:kubectl) ------>API Server
- APIServer需要对客户端做认证,使用kubeadm安装的K8s,会在用户家目录下创建一个认证配置文件 .kube/config 这里面保存了客户端访问API Server的密钥相关信息,这样当用kubectl访问k8s时,它就会自动读取该配置文件,向API Server发起认证,然后完成操作请求。
用户名称可以在kubeconfig中查看
python
cd ~/.kube/
ls
cache config http-cache
cat config
python
users:
- name: kubernetes-admin
ServiceAccount是Pod使用的账号,Pod容器的进程需要访问API Server时用的就是ServiceAccount账户;ServiceAccount仅局限它所在的namespace,每个namespace创建时都会自动创建一个default service account;创建Pod时,如果没有指定Service Account,Pod则会使用default Service Account。
ServiceAccount使用案例介绍
创建sa,并绑定到pod
创建sa
python
kubectl create sa sa-test
创建pod
python
cat pod.yaml
python
apiVersion: v1
kind: Pod
metadata:
name: sa-test
namespace: default
labels:
app: sa
spec:
serviceAccountName: sa-test
containers:
- name: sa-tomcat
ports:
- containerPort: 80
image: nginx
imagePullPolicy: IfNotPresent
python
kubectl apply -f pod.yaml
python
kubectl exec -it sa-test -- /bin/bash
root@sa-test:/# cd /var/run/secrets/kubernetes.io/serviceaccount/
root@sa-test:/var/run/secrets/kubernetes.io/serviceaccount# curl --cacert ./ca.crt -H "Authorization: Bearer $(cat ./token)"
显示如下
python
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {},
"status": "Failure",
"message": "namespaces \"kube-system\" is forbidden: User \"system:serviceaccount:default:sa-test\" cannot get resource \"namespaces\" in API group \"\" in the namespace \"kube-system\"",
"reason": "Forbidden",
"details": {
"name": "kube-system",
"kind": "namespaces"
},
"code": 403
}
上面结果能看到sa能通过https方式成功认证API,但是没有权限访问k8s资源,所以code状态码是403,表示没有权限操作k8s资源
对sa做授权
python
kubectl create clusterrolebinding sa-test-admin --clusterrole=cluster-admin --serviceaccount=default:sa-test
再次请求
python
kubectl exec -it sa-test -- /bin/bash
root@sa-test:/# cd /var/run/secrets/kubernetes.io/serviceaccount/
root@sa-test:/var/run/secrets/kubernetes.io/serviceaccount# curl --cacert ./ca.crt -H "Authorization: Bearer $(cat ./token)"
显示如下
python
{
"kind": "Namespace",
"apiVersion": "v1",
"metadata": {
"name": "kube-system",
"uid": "c392fcb2-12da-4419-b5de-6e2fe2ca626a",
"resourceVersion": "28",
"creationTimestamp": "2022-09-18T06:19:42Z",
"labels": {
"kubernetes.io/metadata.name": "kube-system"
},
"managedFields": [
{
"manager": "kube-apiserver",
"operation": "Update",
"apiVersion": "v1",
"time": "2022-09-18T06:19:42Z",
"fieldsType": "FieldsV1",
"fieldsV1": {
"f:metadata": {
"f:labels": {
".": {},
"f:kubernetes.io/metadata.name": {}
}
}
}
}
]
},
"spec": {
"finalizers": [
"kubernetes"
]
},
"status": {
"phase": "Active"
}
}
通过上面可以看到,对sa做授权之后就有权限访问k8s资源了