目录
一.Kubernetes安全控制介绍
1.客户端认证操作
两者最终都是面向kubernetes的
(1)user account
单独位于kubernetes外的用户账号
(2)service account
kubernetes管理账号,为pod中的服务进程在访问kubernete时提供身份标识
2.访问对象资源依次流程
(1)Authentication认证
所有请求都要经过apiserver,这里进行身份认证,只认准正确的账号
(2)Authorization
账号认证通过后进行资源权限判定,授权发生在认证成功之后,这时候就知道请求用户是谁, Kubernetes就会根据事先定义的授权策略来决定用户是否有权限访问。请求报文一般包含这些内容,请求的用户、请求的路径、请求的动作等,kubernetes将这些内容与事先定义好的策略比对,如果符合策略,则认为授权通过,否则会错误。
(3)Admission Control
准入控制,实现更加精细的访问控制
二.授权管理介绍
我是以kubeadm安装的kubernetes,主要是用到rbac的角色访问控制。
实际上apiserver支持至少六种授权策略:
1.AlwaysDeny
表示拒绝所有请求,通常不使用哈
2.AlwaysAllow
默认的策略,允许接收所有请求,就相当于没进行权限控制
3.ABAC
表示使用用户配置的授权规则对用户请求进行匹配和控制(基于用户属性)
4.Webhook
引用外部REST服务对用户进行授权管理
5.Node
用于对kubelet发出的请求进行访问控制,比较特殊的一种模式
6.RBAC
基于角色访问控制,一般是需要账号等
三.Role解释
理解为哪些对象拥有哪些权限,如下介绍RBAC的四个顶级资源对象(Role、Rolebinding、ClusterRole、ClusterRoleBinding)
1.Role和ClusterRole
角色,可以为角色指定一组权限,指定什么权限该角色就拥有什么权限,一个角色一组权限
(1)Role,是对指定的命名空间的资源进行权限配置,是需要指定名称空间的
#rule中的参数用来对授权进行配置
rules:
- apiGroups: [""] #支持的API组列表,"" 空字符串,表示核心API群
resources: ["pods"] #支持的资源对象列表
verbs: ["get", "watch", "list"] #允许的对资源对象的操作方法列表
(2)ClusterRole,是对整个集群范围内资源(不仅仅限于具体某个名称空间)、非资源类型等进行授权配置
2.Rolebinding和ClusterBinding
角色绑定,将角色绑定给目标对象,那么目标对象就会拥有该角色的权限
(1)Rolebinding,是将Role和目标对象进行绑定,可以是User、Group和ServiceAccount
# RoleBinding可以将同一namespace中的subject绑定到某个Role下,subject内的对象就会拥有role的权限
subjects:
- kind: User
name: username
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: 定义的的role的名称
apiGroup: rbac.authorization.k8s.io
(2)ClusterRoleBinding,ClusterRoleBinding在整个集群级别的特定的subject与ClusterRole绑定,授予subject内目标权限,用法和Rolebinding一致
3.Rolebinding和ClusterRole
(1)可以将ClusterRole把通过RoleBinding绑定给目标对象,但是由于此时是使用Rolebinding方式,所以ClusterRole此时的作用范围也被局限在特定的namespace中。
(2)集群管理员会在集群范围内预先定义一组通用的角色(ClusterRole),然后在多个命名空间中重复使用这些 ClusterRole,好处是:
通过预定义一组通用的 ClusterRole,可以避免在每个命名空间中都重新定义相同的权限规则,从而节省时间和精力。
使用相同的 ClusterRole 在不同的命名空间中授权,可以确保各个命名空间下的基础授权规则保持一致,简化了权限管理并提供一致的用户体验。
当需要更新权限规则时,只需修改预定义的 ClusterRole,所有引用该 ClusterRole 的 RoleBinding 将自动应用新的权限规则,避免了在每个命名空间中手动更新权限规则的繁琐过程。
四.准入控制
用户的权限请求时要通过准入控制后最后才会被apiserver去判断是否处理,通过则继续处理,否则驳回请求
1.命令格式
--admission-control=配置的控制器列表,多个参数用","隔开
2.可配置控制器
参数 | 含义 |
---|---|
AlwaysAdmit | 允许所有请求 |
AlwaysDeny | 禁止所有请求,通常不用哈 |
AlwaysPullImages | 在启动容器之前总去下载镜像 |
DenyExecOnPrivileged | 拦截所有想在Privileged Container上执行命令的请求 |
ImagePolicyWebhook | 一个插件,将允许后端的一个Webhook程序来完成admission controller的功能 |
Service Account | 实现ServiceAccount,自动化 |
SecurityContextDeny | 一个插件,将使用SecurityContext的Pod中的定义全部失效 |
ResourceQuota | 用于资源配额管理,观察所有请求,确保在namespace上的配额不会超标 |
LimitRanger | 用于资源限制管理,作用于namespace上,确保对Pod进行资源限制 |
InitialResources | 为未设置资源请求与限制的Pod,根据其镜像的历史资源的使用情况进行设置 |
NamespaceLifecycle | 如果尝试在一个不存在的namespace中创建资源对象,则该创建请求将被拒绝。当删除一个namespace时,系统将会删除该namespace中所有对象。 |
DefaultStorageClass | 为了实现共享存储的动态供应,为未指定StorageClass或PV的PVC尝试匹配默认的StorageClass,尽可能减少用户在申请PVC时所需了解的后端存储细节 |
DefaultTolerationSeconds | 一个插件,为那些没有设置forgiveness tolerations并具有notready:NoExecute和unreachable:NoExecute两种taints的Pod设置默认的"容忍"时间,为5min |
PodSecurityPolicy | 一个插件,用于在创建或修改Pod时决定是否根据Pod的security context和可用的PodSecurityPolicy对Pod的安全策略进行控制 |
五.例子
配置一个sulibao用户,限制其只能对ns-sulibao名称空间内的pod进行get, watch, list三个行为
1.生成签署证书
[root@k8s-master ~]# cd /etc/kubernetes/pki/
[root@k8s-master pki]# (umask 077; openssl genrsa -out sulibao.key 2048) #生成.key,在当前生效
Generating RSA private key, 2048 bit long modulus
............................+++
...........................................................+++
e is 65537 (0x10001)
[root@k8s-master pki]# openssl req -new -key sulibao.key -out sulibao.csr -subj "/CN=sulibao/O=sulibao"
#生成.csr,用sulibao用户和组进行签署
[root@k8s-master pki]# ll
total 64
-rw-r--r-- 1 root root 1285 Mar 9 11:24 apiserver.crt
-rw-r--r-- 1 root root 1155 Mar 9 11:24 apiserver-etcd-client.crt
-rw------- 1 root root 1679 Mar 9 11:24 apiserver-etcd-client.key
-rw------- 1 root root 1679 Mar 9 11:24 apiserver.key
-rw-r--r-- 1 root root 1164 Mar 9 11:24 apiserver-kubelet-client.crt
-rw------- 1 root root 1675 Mar 9 11:24 apiserver-kubelet-client.key
-rw-r--r-- 1 root root 1107 Mar 9 11:24 ca.crt
-rw------- 1 root root 1675 Mar 9 11:24 ca.key
drwxr-xr-x 2 root root 162 Mar 9 11:24 etcd
-rw-r--r-- 1 root root 1123 Mar 9 11:24 front-proxy-ca.crt
-rw------- 1 root root 1679 Mar 9 11:24 front-proxy-ca.key
-rw-r--r-- 1 root root 1119 Mar 9 11:24 front-proxy-client.crt
-rw------- 1 root root 1675 Mar 9 11:24 front-proxy-client.key
-rw------- 1 root root 1679 Mar 9 11:24 sa.key
-rw------- 1 root root 451 Mar 9 11:24 sa.pub
-rw-r--r-- 1 root root 911 Mar 9 19:32 sulibao.csr
-rw------- 1 root root 1679 Mar 9 19:31 sulibao.key
#用apiserver证书签署
[root@k8s-master pki]# openssl x509 -req -in sulibao.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out sulibao.csr -days 3650
#生成
Signature ok
subject=/CN=sulibao/O=sulibao
Getting CA Private Key
[root@k8s-master pki]# kubectl config set-cluster kubernetes --embed-certs=true --certificate-authority=/etc/kubernetes/pki/ca.crt --server=https://192.168.2.150:6443
Cluster "kubernetes" set.
2.设置用户和上下文信息
[root@k8s-master pki]# kubectl config set-credentials sulibao --embed-certs=true --client-certificate=/etc/kubernetes/pki/sulibao.csr --client-key=/etc/kubernetes/pki/sulibao.key
User "sulibao" set.
[root@k8s-master pki]# kubectl config set-context sulibao@kubernetes --cluster=kubernetes --user=sulibao
Context "sulibao@kubernetes" created.
[root@k8s-master pki]# kubectl config use-context sulibao@kubernetes
Switched to context "sulibao@kubernetes".
#当前无权限
[root@k8s-master pki]# kubectl get pods -n ns-sulibao
Error from server (Forbidden): pods is forbidden: User "sulibao" cannot list resource "pods" in API group "" in the namespace "ns-sulibao"
[root@k8s-master pki]# kubectl config use-context kubernetes-admin@kubernetes
Switched to context "kubernetes-admin@kubernetes".
3.为sulibao用户授权
[root@k8s-master pki]# vim role.yaml
apiVersion: v1
kind: Namespace
metadata:
name: ns-sulibao
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: ns-sulibao
name: ns-sulibao-role
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: authorization-role-binding
namespace: ns-sulibao
subjects:
- kind: User
name: sulibao
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: ns-sulibao-role
apiGroup: rbac.authorization.k8s.io
[root@k8s-master pki]# kubectl apply -f role.yaml
namespace/ns-sulibao created
role.rbac.authorization.k8s.io/ns-sulibao-role created
rolebinding.rbac.authorization.k8s.io/authorization-role-binding created
[root@k8s-master pki]# vim test-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: my-nginx
namespace: ns-sulibao
spec:
containers:
- name: nginx-sulibao
image: nginx
ports:
- containerPort: 80
[root@k8s-master pki]# kubectl apply -f test-pod.yaml
pod/my-nginx created
[root@k8s-master pki]# kubectl get pods -n ns-sulibao
NAME READY STATUS RESTARTS AGE
my-nginx 1/1 Running 0 7s
[root@k8s-master pki]# kubectl config use-context sulibao@kubernetes
Switched to context "sulibao@kubernetes".
[root@k8s-master pki]# kubectl get pods -n ns-sulibao #已有权限
NAME READY STATUS RESTARTS AGE
my-nginx 1/1 Running 0 32s
[root@k8s-master pki]#