一、k8s安全管理:认证、授权、准入控制概述
k8s对我们整个系统的认证,授权,访问控制做了精密的设置;对于k8s集群来说,apiserver是整个集群访问控制的唯一入口,我们在k8s集群之上部署应用程序的时候,也可以通过宿主机的NodePort暴露的端口访问里面的程序,用户访问kubernetes集群需要经历如下认证过程:
1.认证(Authenticating)是对客户端的认证,通俗点就是用户名密码验证
2.授权(Authorization)是对资源的授权,k8s中的资源无非是容器,最终其实就是容器的计算,网络,存储资源,当一个请求经过认证后,需要访问某一个资源(比如创建一个pod),授权检查会根据授权规则判定该资源(比如某namespace下的pod)是否是该客户可访问的。
3.准入(Admission Control)机制:
准入控制器(Admission Controller)位于 API Server中,在对象被持久化之前,准入控制器拦截对 API Server 的请求,一般用来做身份验证和授权。其中包含两个特殊的控制器:
Mutating Admission Webhook 和 Validating Admission Webhook。分别作为配置的变更和验证准入控制 webhook。
变更(Mutating)准入控制:修改请求的对象
验证(Validating)准入控制:验证请求的对象
准入控制器是在 API Server 的启动参数配置的。一个准入控制器可能属于以上两者中的一种,也可能两者都属于。当请求到达 API Server 的时候首先执行变更准入控制,然后再执行验证准入控制。
我们在部署 Kubernetes 集群的时候都会默认开启一系列准入控制器,如果没有设置这些准入控制器的话可以说你的 Kubernetes 集群就是在裸奔,应该只有集群管理员可以修改集群的准入控制器。
k8s的整体架构也是一个微服务的架构,所有的请求都是通过一个GateWay,也就是kube-apiserver这个组件(对外提供REST服务),k8s中客户端有两类,一种是普通用户,一种是集群内的Pod,这两种客户端的认证机制略有不同,但无论是哪一种,都需要依次经过认证,授权,准入这三个机制。
1.1 认证
1、认证支持多种插件
(1)令牌(token)认证:
双方有一个共享密钥,服务器上来先创建一个密码下来,客户端登陆的时候拿这个密码登陆即可,这个就是对称密钥认证方式;k8s提供了一个restful风格的接口,它的所有服务都是通过http协议提供的,因此认证信息只能经由http协议的认证首部进行传递,这种认证首部进行传递通常叫做令牌;
(2)ssl认证(TLS):
对于k8s访问来讲,ssl认证能让客户端确认服务器的认证身份,我们在跟服务器通信的时候,需要服务器发过来一个证书,我们需要确认这个证书是不是ca签署的,如果是我们认可的ca签署的,里面的subj信息与我们访问的目标主机信息保持一致,没有问题,那么我们就认为服务器的身份得到认证了,k8s中最重要的是服务器还需要认证客户端的信息,kubectl也应该有一个证书,这个证书也是server所认可的ca签署的证书,双方需要互相认证,实现加密通信,这就是ssl认证。
2、kubernetes上的账号
客户端对apiserver发起请求,apiserver要识别这个用户是否有请求的权限,要识别用户本身能否通过apiserver执行相应的操作,那么需要哪些信息才能识别用户信息来完成对用户的相关的访问控制呢?
kubectl explain pods.spec 可以看到有一个字段serviceAccountName(服务账号名称),这个就是我们pod连接apiserver时使用的账号,因此整个kubernetes集群中的账号有两类,ServiceAccount(服务账号),User account(用户账号)
User account:实实在在现实中的人,人可以登陆的账号,客户端想要对apiserver发起请求,apiserver要识别这个客户端是否有请求的权限,那么不同的用户就会有不同的权限,靠用户账号表示,叫做username
ServiceAccount:方便Pod里面的进程调用Kubernetes API或其他外部服务而设计的,是kubernetes中的一种资源
sa账号:登陆dashboard使用的账号
user account:这个是登陆k8s物理机器的用户(系统用户)
1.ServiceAccount
Service account是为了方便Pod里面的进程调用Kubernetes API或其他外部服务而设计的。它与User account不同,User account是为人设计的,而service account则是为Pod中的进程调用Kubernetes API而设计;User account是跨namespace的,而service account则是仅局限它所在的namespace;每个namespace都会自动创建一个default service account;
开启ServiceAccount Admission Controller后
1)每个Pod在创建后都会自动设置spec.serviceAccount为**default(**除非指定了其他ServiceAccout)
2)验证Pod引用的service account已经存在,否则拒绝创建;
当创建 pod 的时候,如果没有指定一个 serviceaccount,系统会自动在与该pod 相同的 namespace 下为其指派一个default service account。这是pod和apiserver之间进行通信的账号,如下:
bash
[root@k8s-master01 ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
mysql-pod-volume 1/1 Running 0 43m
nfs-provisioner-cd5589cfc-c8vc5 1/1 Running 0 13h
pod-secret 1/1 Running 0 18m
web-0 1/1 Running 0 13h
web-1 1/1 Running 0 13h
[root@k8s-master01 ~]# kubectl get pods web-0 -o yaml | grep "serviceAccountName"
serviceAccountName: default
[root@k8s-master01 ~]# kubectl get sa
NAME SECRETS AGE
default 0 12d
1.2 授权
如果用户通过认证,什么权限都没有,需要一些后续的授权操作,如对资源的增删该查等,kubernetes1.6之后开始有RBAC(基于角色的访问控制机制)授权检查机制。(role basic access control)
Kubernetes的授权是基于插件形成的,其常用的授权插件有以下几种:
-
Node(节点认证)
-
ABAC(基于属性的访问控制)
-
RBAC(基于角色的访问控制)(Role Basic Access Control)
-
Webhook(基于http回调机制的访问控制)
两个角色绑定:
(1)用户通过rolebinding绑定role
(2)用户通过clusterrolebinding绑定clusterrole
还有一种:rolebinding绑定clusterrole
rolebinding绑定clusterrole的好处:
假如有6个名称空间,每个名称空间的用户都需要对自己的名称空间有管理员权限,那么需要定义6个role和rolebinding,然后依次绑定,如果名称空间更多,我们需要定义更多的role,这个是很麻烦的,所以我们引入clusterrole,定义一个clusterrole,对clusterrole授予所有权限,然后用户通过Clusterrolebinding绑定到clusterrole,就会拥有自己名称空间的管理员权限了
限制不同的用户操作k8s集群(重点)
ssl认证
生成一个证书
(1)生成一个私钥
bash
cd /etc/kubernetes/pki/
umask 077; openssl genrsa -out lucky.key 2048
(2)生成一个证书请求
bash
openssl req -new -key lucky.key -out lucky.csr -subj "/CN=lucky"
(3)生成一个证书
bash
openssl x509 -req -in lucky.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out lucky.crt -days 3650
在kubeconfig下新增加一个lucky这个用户
(1)把lucky这个用户添加到kubernetes集群中,可以用来认证apiserver的连接
bash
[root@xianchaomaster1 pki]# kubectl config set-credentials lucky --client-certificate=./lucky.crt --client-key=./lucky.key --embed-certs=true
(2)在kubeconfig下新增加一个lucky这个账号
bash
[root@k8s-master01 pki]# kubectl config use-context lucky@kubernetes
[root@k8s-master01 pki]# kubectl get pod
Error from server (Forbidden): pods is forbidden: User "lucky" cannot list resource "pods" in API group "" in the namespace "default"
###切换到有权限的管理账户
[root@k8s-master01 pki]# kubectl config use-context kubernetes-admin@kubernetes
这个是集群用户,有任何权限;把lucky这个用户通过rolebinding绑定到clusterrole上,授予权限,权限只是在lucky这个名称空间有效
(1)把lucky这个用户通过rolebinding绑定到clusterrole上
bash
[root@k8s-master01 pki]# kubectl create ns lucky
[root@k8s-master01 pki]# kubectl create rolebinding lucky -n lucky --clusterrole=cluster-admin --user=lucky
(2)切换到lucky这个用户
bash
[root@k8s-master01 pki]# kubectl config use-context lucky@kubernetes
(3)测试是否有权限
bash
kubectl get pods -n lucky
[root@k8s-master01 pki]# kubectl get pod -n lucky
No resources found in lucky namespace.
[root@k8s-master01 pki]# kubectl get sa -n lucky
NAME SECRETS AGE
default 0 2m10s
#有权限操作这个名称空间
kubectl get pods
[root@k8s-master01 pki]# kubectl get pod
Error from server (Forbidden): pods is forbidden: User "lucky" cannot list resource "pods" in API group "" in the namespace "default"
#没有权限操作其他名称空间
添加一个lucky的普通用户
bash
useradd lucky
cp -ar /root/.kube/ /home/lucky/
chown -R lucky.lucky /home/lucky/
su - lucky
vim .kube/config
.......
server: https://192.168.158.15:6443
name: kubernetes
contexts:
- context:
cluster: kubernetes
user: lucky
name: lucky@kubernetes
current-context: lucky@kubernetes
....
su - root
chattr +i /home/lucky/.kube/config
exit
kubectl get pods -n lucky
验证创建pod:
bash
[lucky@k8s-master ~]$ cat nginx.txt
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
[lucky@k8s-master ~]$ kubectl apply -f nginx.txt
##发现报错
Error from server (Forbidden): error when retrieving current configuration of:
Resource: "/v1, Resource=pods", GroupVersionKind: "/v1, Kind=Pod"
Name: "nginx-pod", Namespace: "default"
from server for: "nginx.txt": pods "nginx-pod" is forbidden: User "lucky" cannot get resource "pods" in API group "" in the namespace "default"
[lucky@k8s-master ~]$ cat nginx.txt
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
namespace: lucky
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
[lucky@k8s-master ~]$ kubectl apply -f nginx.txt
##发现成功创建
pod/nginx-pod created
[lucky@k8s-master ~]$ kubectl -n lucky get po
NAME READY STATUS RESTARTS AGE
nginx-pod 1/1 Running 0 28s