k8s权威指南第六章----深入分析集群安全机制

K8S权威指南下载地址:

kubernetes权威指南第5版

1、API Server 认证管理

K8s集群有两种认证方式：
ServiceAccount 和 普通用户

api server 访问方式:
1)kubectl kubelets
2)ServiceAccount
3)匿名方式

k8s提供的认证方式,这些方式都不仔细看了，了解下就好:
1)https 证书
2）Http Bearer Token
3) OpenId Connect Token
4)Webhook Token
5)Authenticating Proxy 认证

2、ApiSever 授权管理

K8s 授权方式：
AlowysDeny：表示拒绝所有请求
AlowysAllow：表示运行徐所有请求
ABAC：基于属性的访问控制
RBAC：基于角色的访问控制字
WebHook：通过调用外部的REST API进行授权
Node：对kubelet的一种特殊模式

1）webhook

2）RBAC

直接看RBAC

要使用 RBAC 授权模式，首先需要在 ku e-apiserver 服务的启动参数 uthorization-mode，（授权模式）的列表中加上 RBAC, 例如 --authorization-rnode =...,RBAC

RBAC引入的资源对象Role、ClusterRole、RoleBinding、ClusterRoleBinding这4个

Role:

[root@vm50 eoi]# kubectl get Role -A
NAMESPACE     NAME                                             CREATED AT
kube-public   kubeadm:bootstrap-signer-clusterinfo             2022-04-19T09:25:09Z
kube-public   system:controller:bootstrap-signer               2022-04-19T09:25:08Z
kube-system   extension-apiserver-authentication-reader        2022-04-19T09:25:08Z
kube-system   kube-proxy                                       2022-04-19T09:25:10Z
kube-system   kubeadm:kubelet-config-1.23                      2022-04-19T09:25:08Z
kube-system   kubeadm:nodes-kubeadm-config                     2022-04-19T09:25:08Z
kube-system   system::leader-locking-kube-controller-manager   2022-04-19T09:25:08Z
kube-system   system::leader-locking-kube-scheduler            2022-04-19T09:25:08Z
kube-system   system:controller:bootstrap-signer               2022-04-19T09:25:08Z
kube-system   system:controller:cloud-provider                 2022-04-19T09:25:08Z
kube-system   system:controller:token-cleaner                  2022-04-19T09:25:08Z

看一下一个定义role的例子

# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  creationTimestamp: "2022-04-19T09:25:10Z"
  name: kube-proxy
  namespace: kube-system
  resourceVersion: "290"
  uid: 0edaccf8-f16e-40d3-85a7-f8ca834d74c0
rules:
- apiGroups:
  - ""
  resourceNames:
  - kube-proxy
  resources:
  - configmaps
  verbs:
  - get
~                                                                                                                                                                 
~          

 resources ：需要操作的资源对象类型列表，例如 “pods” “deployments” “jobs”
apiGroups ：资源对象 API 组列表，例如 “”(Core) “extensions” “apps” “batch"
verbs ：设置允许对资源对象操作的方法列表，例如 “get” 'watch” “list” “delete”"replace” “patch”

Cluster Role

对集群范围内资源的授权，例如 Node
对非资源型 授权 ，例如 healthz
对包含全部 namespace 资源的授权 例如 pods (用于 kubectl get pods --all namespaces 这样的操作授权）
对某个命名空 间中 的一次性授权

RoleBind 和 ClusterRoleBind 

定义主体：

subjects: 
- kind: User 
name: jane 
apiGroup: rbac.authorization.k8s.io

定义好ref就可以

roleRef: 
kind: Role 
name : pod- reader 
apiGroup: rbac.authorization.k8s.io

一但绑定好roleBind和clusterRoleBind后就不能进行Role和ClusterRole修改

使用kubectl 管理RBAC

创建role 允许对pod进行get watch list

kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods

创建rolebinding的例子:

kubectl create rolebinding myappnamespace-myapp-vie1,-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=default

更新配置

kubec auth reconcile -f my-rbac- rules.yaml

3、POD安全策略

默认的安全配置：- --enable-admission-plugins=NodeRestriction

注意，在开启 PodSecurityPolicy 准人控制器后，系统中还没有任何 PodSecurityPolicy
策略配置时， Kubernetes 默认不允许创建任何 Pod, 要管理员创建适合的PodSecurityPolicy 策略和相应的 RBAC 授权策略， Pod 才能创建成功

PodSecurityPolicy配置详解

1、特权模式

privileged 是否允许容器以特权模式运行

2.宿主机命名空间相关

(1) hostPID 是否允许容器共享宿主机的进程 ID 命名空间 (PID Namespace)
(2) hostIPC: 是否允许容器共享宿主机的 IPC 命名 IPC Namespace)
( 3 ) bostNetwork: 是否允许 od 使用宿主机的网络命名 Network Namespace), 
使用 hostNetwork Pod 将可以访问宿主机的各个网卡
(4) hostPort s: 是否允许 Pod 使用宿主机的端口号，可以通过 hostPortRange 字段设置
允许使用的端口号范围， min, max] 设置最小端口号和最大端口号

3.存储卷和文件系统相关

(1) Volumes: 允许 Pod 使用的存储卷 Volume 类型，设笠为“*”表示允许使用任Volume 类型，建议至少允许 Pod 使用的 Volume 类型有 configMap downwardAPI emptyDr
persistentVolumeC!aim PVC ) 、 secret 和projected

(2) FSGroup 设置允许访问某些 Volume Group ID 范围，规则 (ru le 字段）可被设置为 ustRunAs MayRunAs RunA Any
1、MustRunAs ：需要设置 Group ID 的范围，例如 65535, 要求 Pod ContainersecurityCon text.fsGroup 设置的值必须属于该 Group 1D 范围，如未设置 ，则
系统将自动设置 securityCo ntex t.fsGroup 的值为 Group ID 围的最小值。
2、MayRunAs: 需要设置 Group ID 范围，例如 ~65535, 要求 Pod Container securityContex t.fsGroup 设置的值必须属千该 roup ID 的范 围，如未设置，则系统将不会自动设置默认值。
3、RunAsAny 不限制 Group ID 的范围 Pod Container securityCo ntext. fsGroup 可被设立为任意 Group ID

(3) AllowedHostPaths 允许 Pod 使用宿主机的 hostPath 路径名称，可以通过 pathPrefix字段设置路径的前缀，并设置是否仅允许以只读模式挂载。

(4) readOnlyRootFilesystem 要求容器运行的根文件系统 root filesystem必须是只读的

4、FlexVolume驱动相关

5、用户和相关组配置

(1) runAsUser 设置运行容器的用户 ID (User ID ，规则字段 (rule) 的值可被设登为 MustRunAs MustRunAsNonRoot RunAsAny。
MustRunAs 需要设置 User ID 的范围，要求 Pod Container securityContext runAsUser 设立 的值必须属于该 User ID 的范围，如 未设置，则系统将自动设置securityContext.runAsUser 的值为 User ID 范围的最小值
MustRunAsNonRoot: 须以非 root 用户运行容器，要求在 Pod Container securityContext.runAsUser 中设置 个非 的用户 ID, 或在镜像的 USER 字段设置了用户 ID 如果 Pod 既未设置 runAsNonRoot, 未设置 runAsUser, 则系统将自动设置 runAsNonRoot=true 默认要求在镜像中必须设置非 USER 在该策略生效时，建议同时设置 allowPrivilegeEscalation =false, 以免不必要的权限提升
RunAsAny: 不限制 User ID 的范 围， Pod Container securityContext.runAsUser可被设置为任意 User ID

(2) RunAsGroup 设置运行容器的用户组 Grou ID 范围，可以将规则 (rule)值设置为 MustRnAs MustRunAsNonRoot RunAsAny
MustRun  需要设置 Group ID 范围，要求 PodContainer securityContext runAsGroup 置的值必须属于该 Group ID 范围，如未设置，则系统将自动设置securityContext.runAsGroup 的值为 Group ID 范围内的最小值
MayRunAs 不强制要求 Pod Container 设置 securityContext.runAsGroup, 如果设置了 Group ID 的范围，则仍然要求 Pod Container securityContext
runAsGroup 设置的值必须属于该 Group ID 的范图，如未设置，则系统将不会自动设置默认值
RunAsAny 不限制 Group ID 的范围， Pod Container securityContext.runAsGroup可被设置为任意 Group ID

(3) SupplementalGroup 设置运行容器的用户允许属于的额外 Group ID 范围，规则字段 (rule) 的值可被设置为 MustRunAs MayRunA RunAsAny
MustRunAs: 需要设置 Supplemental Group ID 的范围，要求 Pod Container securityContext. supplementalGroups 设置的值必须属于该 Supplemental Group ID范围，如未设置，则系统将自动设置 ecurityConte xt.supplementa!Groups 的值为Supplemental Group ID 范围内的最小值
MayRunAs ：不强制要求 Pod Container 设置 securityContext.supplementalGroups,
即使设置了 Supplement Group ID 的范围，也仍 要求 PodContainer securityContext. supplemental Groups 设置的值必须属于该 Supplemental Group ID范围，如未设置，则系统将不会自动设置默认值
RunAsAny: 不限制 Supplemental Group ID 的范围 Pod Container securityConte xt.supplemen lGroups 可被设置为任意 Supplemental Group ID

6.提升权限 (Privilege Escalation) 相关配置

提升权限字段用于控制是否允许容器内的进程提升权限 提升权限配置直接影响对容器进程的 "no_new_privs" 标志位的设置，如果设置了该标志位，则将阻止通过 setuid程序修改进程 User ID 的行为，并阻止文件启用额外的功能（例如阻止运行 ping 令）。通常在设置了以非 root 用户 MustRunAsNonRoot) 时设置是否允许提升权限

7.liux 能力配置

1）AllowedCapabilities设置容器可以使用的linux 能力列表，设置*表示允许使用linux所有能力（如：NET_ADMIN，SYS_TIME）

2)RequiredDropCapabilities:设置从容器删除的能力列表

3）DefaultAddDropCapabilities：

设置为容器默认添加的 能力列表

8.selinux配置

通过selinux设置SElinux参数

MustRunAs：

要求POD或者Container设置securityContext.setLinuxOptions,系统将进行校验

RunAsAny：

不校验POD或者Container的securityContext.setLinuxOptions

9.其他linux安全配置

1）AllowedProcMountType:设置 允许的 ProcMountType 类型列表，可以设置为allowedProcMountType或者DefaultProcMount

2)AppArmor:设置容器对程序访问权限的控制

3）Seccomp:设置允许容器使用的系统调用

4）sysctl设置允许跳转的内核参数

 forbiddenSysctls：禁止的sysctl列表，设置为“*”表示禁止全部 sysctl
allowedUnsafeSysctls: 设置允许的不安全 sysctl 表（默认禁用），不应该在forbiddenSysctls 中设置。