OPSaid – CIS 基准

Docs: 控制平面

Fri, 06 Oct 2023 11:02:45 +0800

简要概述

主要关于控制平面相关的安全配置建议。

配置文件

确保静态 POD 文件权限

检查文件权限，必须小于等于 “644”

stat -c %a /etc/kubernetes/manifests/kube-apiserver.yaml
stat -c %a /etc/kubernetes/manifests/kube-controller-manager.yaml
stat -c %a /etc/kubernetes/manifests/kube-scheduler.yaml
stat -c %a /etc/kubernetes/manifests/etcd.yaml

检查文件归属，用户组必须为 “root:root”

stat -c %U:%G /etc/kubernetes/manifests/kube-apiserver.yaml
stat -c %U:%G /etc/kubernetes/manifests/kube-controller-manager.yaml
stat -c %U:%G /etc/kubernetes/manifests/kube-scheduler.yaml
stat -c %U:%G /etc/kubernetes/manifests/etcd.yaml

CNI 文件配置路径，默认为 “/etc/cni/net.d/” 通过 kubelet “–cni-conf-dir” 参数修改。

stat -c %a /etc/cni/net.d/10-containerd-net.conflist
stat -c %U:%G /etc/cni/net.d/10-containerd-net.conflist

确保 etcd 数据目录安全

通过查询 “–data-dir” 或 “$DATA_DIR” 定位数据目录，如："/data/etcd/"。

stat -c %a /data/etcd/
stat -c %U:%G /data/etcd/

权限需小于等于 “700” 且用户归宿为 “etcd:etcd”。

确保 kubeconfig 文件权限

stat -c %a /etc/kubernetes/admin.conf
stat -c %a /etc/kubernetes/scheduler.conf
stat -c %a /etc/kubernetes/controller-manager.conf

stat -c %U:%G /etc/kubernetes/admin.conf
stat -c %U:%G /etc/kubernetes/scheduler.conf
stat -c %U:%G /etc/kubernetes/controller-manager.conf

权限需小于等于 “600” 。

确保 pki 文件权限

ls -laR /etc/kubernetes/pki/
ls -laR /etc/kubernetes/pki/*.crt
ls -laR /etc/kubernetes/pki/*.key

归宿用户 root:root 且 “.crt” 权限小于等于 644, “.key” 权限为 600

kube-apiserver

确保关闭匿名请求

启动参数 “–anonymous-auth” 设置为 “false”，如：

spec:
 containers:
 - command:
 - kube-apiserver
 - --anonymous-auth=false

如果开启匿名，不带 token 的请求均属于 “system:anonymous” 用户组，访问未授权的资源以 “403” 状态码相应，内容如：

{
 "kind": "Status",
 "apiVersion": "v1",
 "metadata": {

 },
 "status": "Failure",
 "message": "forbidden: User \"system:anonymous\" cannot get path \"/metrics\"",
 "reason": "Forbidden",
 "details": {

 },
 "code": 403
}

关闭匿名后，则以 “401” 状态码响应：

{
 "kind": "Status",
 "apiVersion": "v1",
 "metadata": {

 },
 "status": "Failure",
 "message": "Unauthorized",
 "reason": "Unauthorized",
 "code": 401
}

确保与 kubelet 通讯安全

spec:
 containers:
 - command:
 - kube-apiserver
 - --kubelet-https=true
 - --kubelet-client-certificate=<path/to/client-certificate-file>
 - --kubelet-client-key=<path/to/client-key-file>

参数 “–kubelet-https” 无需设置，在新版中以被移除，强制使用 https 通讯。

确保使用合适的认证模式

spec:
 containers:
 - command:
 - kube-apiserver
 --authorization-mode=Node,RBAC
 --enable-admission-plugins=...(not AlwaysAdmit)...

避免使用 “AlwaysAllow” 认证模式与 “AlwaysAdmit” 准入控制器，以允许所有请求。

取保使用合适的拉取镜像策略

强制每次创建 POD 时均从镜像中心拉取，而不使用本地镜像缓存，通过添加 “AlwaysPullImages” 准入控制器实现。

spec:
 containers:
 - command:
 - kube-apiserver
 --enable-admission-plugins=...,AlwaysPullImages,...

在多租户集群中，即使各租户对各自镜像使用单独的授权，但租户A在宿主1上拉取了镜像m存在缓存，而租户B知道镜像m的名称后，如果没有该限制则可以使用此镜像m创建出容器。

确保几个基础准入控制器策略

spec:
 containers:
 - command:
 - kube-apiserver
 --enable-admission-plugins=...,NamespaceLifecycle,ServiceAccount,NodeRestriction...

ServiceAccount

当创建 POD 时如果未指定 “serviceAccount” 则自动关联至该命名空间下的 “default” 服务账号。

NamespaceLifecycle

控制命名空间删除操作会触发一系列删除该空间中所有对象（Pod、Service 等）的操作，同时也限制在一个正在被删除的命名空间中创建新对象，并确保针对不存在的命名空间请求拒绝。该准入控制器还会禁止删除三个系统保留的名字空间，即 default、 kube-system 和 kube-public。

NodeRestriction

确保 kubelet 具有正常运行所需的最小权限集。

确保关闭性能调试信息

spec:
 containers:
 - command:
 - kube-apiserver
 - --profiling=false

分析允许识别特定的性能瓶颈。它生成了大量的程序数据，这些数据可能被用来揭示系统和程序的详细信息。如果您没有遇到任何瓶颈，并且不需要探查器进行故障排除，建议将其关闭，以减少潜在的攻击面。

kube-controller-manager

确保垃圾回收值在合理范围

spec:
 containers:
 - command:
 - kube-controller-manager
 - --terminated-pod-gc-threshold=10

通过设置 --terminated-pod-gc-threshold 达到值触发垃圾回收，默认值为 “12500” 太大，一般集群无法保证，需根据实际情况降低。

确保关闭性能调试信息

同 kube-apiserver 组件。

确保为每个控制器使用单独的账号

spec:
 containers:
 - command:
 - kube-controller-manager
 - --use-service-account-credentials=true

通过设置 --use-service-account-credentials 以达到在 kube-system 空间下每个控制器使用各自的认证，可通过以下指令查看：

root@limiqi-dell-01:~# kubectl get sa -n kube-system
NAME SECRETS AGE
attachdetach-controller 1 34h
calico-kube-controllers 1 32h
calico-node 1 32h
certificate-controller 1 34h
clusterrole-aggregation-controller 1 34h
coredns 1 32h
cronjob-controller 1 34h
daemon-set-controller 1 34h
......

确保服务帐户令牌的密钥可以根据需要轮换

spec:
 containers:
 - command:
 - kube-controller-manager
 - --service-account-private-key-file=/etc/kubernetes/pki/sa.key

应使用单独的公私钥对对服务帐户令牌进行签名，通过设置 --service-account-private-key-file 将私钥指定给控制器管理器。

spec:
 containers:
 - command:
 - kube-apiserver
 - --service-account-signing-key-file=/etc/kubernetes/pki/sa.key
 - --service-account-key-file=/etc/kubernetes/pki/sa.pub

这里公私钥同 “kube-apiserver” 中的 --service-account-signing-key-file --service-account-key-file 配置，如果未提供，则默认会使用 --tls-private-key-file 指定的文件进行令牌签名，该证书用于服务端 6443 通讯，变更代价较大，所以需把服务账户令牌单独签名。

确保开启 kubelet 证书自动轮换

spec:
 containers:
 - command:
 - kube-controller-manager
 - --feature-gates=RotateKubeletServerCertificate=true

以上特性 --feature-gates=RotateKubeletServerCertificate=true 默认是开启的，所以只要确保未设置或非设置为 “false” 即可。

具体流程可参考: https://kubernetes.io/zh-cn/docs/tasks/tls/certificate-rotation/。

kube-scheduler

确保关闭性能调试信息

同 kube-apiserver 组件。

Docs: Etcd集群

Mon, 09 Oct 2023 14:06:20 +0800

简要概述

etcd 集群安全相关。

etcd

确保客户端通过 tls 通讯

spec:
 containers:
 - command:
 - etcd
 - --cert-file=/etc/kubernetes/pki/etcd/server.crt
 - --key-file=/etc/kubernetes/pki/etcd/server.key

确保客户端通过 tls 认证

spec:
 containers:
 - command:
 - etcd
 - --client-cert-auth="true"

确保集群间通过 tls 通讯

spec:
 containers:
 - command:
 - etcd
 - --peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt
 - --peer-key-file=/etc/kubernetes/pki/etcd/peer.key

确保集群间通过 tls 认证

spec:
 containers:
 - command:
 - etcd
 --peer-client-cert-auth=true

确保配置正确的 ca 用于验证

spec:
 containers:
 - command:
 - etcd
 - --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
 - --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt

Docs: 认证审计

Mon, 09 Oct 2023 14:31:34 +0800

简要概述

认证与审计配置相关。

集群认证

确保不对外提供客户端证书认证

虽然集群有提供 tls 认证，但是不建议对业务部门使用，因为由于人员流动后，无法对以提供的证书进行回收。

日志审计

确保最小化的审计策略

spec:
 containers:
 - command:
 - kube-apiserver
 - --audit-policy-file=/etc/kubernetes/audit-policy.yaml

参考 https://kubernetes.io/zh-cn/docs/tasks/debug/debug-cluster/audit/。

Docs: 工作节点

Tue, 10 Oct 2023 18:08:58 +0800

简要概述

关于在工作节点上组件的安全配置建议。

配置文件

确保 kubelet 配置文件权限

文件权限必须小于等于 “644”

stat -c %a /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
stat -c %a /etc/systemd/system/kubelet.service
stat -c %a /etc/default/kubelet
stat -c %a /etc/kubernetes/kubelet.conf
stat -c %a /var/lib/kubelet/config.yaml

文件归属用户必须为 “root:root”

stat -c %U:%G /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
stat -c %U:%G /etc/systemd/system/kubelet.service
stat -c %U:%G /etc/default/kubelet
stat -c %U:%G /etc/kubernetes/kubelet.conf
stat -c %U:%G /var/lib/kubelet/config.yaml

确保未开启匿名访问

kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
staticPodPath: /etc/kubernetes/manifests
address: 192.168.0.2
port: 10250
readOnlyPort: 0
authentication:
 anonymous:
 enabled: false
 webhook:
 enabled: true
 cacheTTL: 2m0s
 x509:
 clientCAFile: /etc/kubernetes/pki/ca.crt

以上配置 “authentication.anonymous.enabled” 设置为 “false”

确保鉴权模式非允许所有

kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
authorization:
 mode: Webhook
 webhook:
 cacheAuthorizedTTL: 5m0s
 cacheUnauthorizedTTL: 30s

以上配置 “authorization.mode” 非设置为 “AlwaysAllow”，避免敏感数据 “kubelet:10250/configz” 等被非法获取。

确保开启 kubelet 验证来自 kube-apiserver 请求

kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
authentication:
 x509:
 clientCAFile: /etc/kubernetes/pki/ca.crt

从 kube-apiserver 到 kubelet 的连接在以下三个地址会使用到：

用于获取 pod 日志；
连接到正在运行的 pod；
使用 kubelet 端口转发功能。

默认情况下 kube-apiserver 不会验证 kubelet 的服务证书，这会使连接受到中间人攻击，并且在不受信任的网络上运行。

通过设置 “authentication.x509.clientCAFile” 启用 kubelet 证书身份验证同时需保证 kube-apiserver 配置的地址配置了以下参数：

--kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt
--kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key

如果证书不匹配时，从 kube-apiserver 至 kubelet 会出现以下错误日志：

kubectl exec -i -t default-ingress-nginx-controller-7gb62 /bin/bash -n kube-system

journalctl -f /usr/bin/kubelet

Oct 12 14:06:07 limiqi-dell-01 kubelet[1967008]: E1012 14:06:07.419980 1967008 server.go:273] "Unable to authenticate the request due to an error" err="verifying certificate SN=13890730310367349504, SKID=, AKID= failed: x509: certificate signed by unknown authority"

确保关闭只读端口配置

kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
staticPodPath: /etc/kubernetes/manifests
address: 192.168.0.2
port: 10250
readOnlyPort: 0

Kubelet 除了提供 “https 10250” 端口外，还提供了只读的 “http 10255” 协议端口，对该只读接口提供未经身份验证的访问，该访问可能会检索到有关群集的潜在敏感信息，通过设置 “readOnlyPort=0” 关闭。

确保长连接配置最大超时时间

kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
streamingConnectionIdleTimeout: 4h

kubectl port-forward pod/coredns-c66bbd748-b9tfw --address 0.0.0.0 9153 -n kube-system

TODO;

确保内核参数符合预期否则禁止启动

kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
protectKernelDefaults: true

设置为 true 时，会令 kubelet 在发现内核参数与预期不符时出错退出。

若此字段设置为 false，则 kubelet 会尝试更改内核参数以满足其预期。

以下示例更改 vm.overcommit_memory 值为 0 测试不符合预期，则导致 “kubelet” 无法启动。

sysctl -w vm.overcommit_memory=0

Oct 12 15:58:45 limiqi-dell-01 kubelet[2004079]: E1012 15:58:45.018694 2004079 kubelet.go:1423] "Failed to start ContainerManager" err="invalid kernel flag: vm/overcommit_memory, expected value: 1, actual value: 0"

内核参数通常由系统管理员在将系统投入生产之前进行调整和强化。这些参数保护内核和系统。依赖于这些参数的kubelet内核默认值应该适当设置，以匹配所需的安全系统状态。忽略这一点可能会导致运行带有不希望的内核行为的pod。

确保允许 Kubelet 管理 iptables 规则

kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
makeIPTablesUtilChains: true

可以根据设置的网络模式自动管理 iptables 所需的更改，建议让 kubelet 来进行管理。这确保了 iptables 配置与 pods 网络配置保持同步，通过动态 pod 网络配置更改手动配置 iptables 可能会阻碍 pod 与容器之间以及与外部世界的通信。您的 iptables 规则可能过于严格或过于开放。

但不要在使用其他 iptables 管理工具，可能会存在冲突。

确保未覆盖主机节点名称

TODO;

确保 kubelet 开启 https 链接

kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
tlsCertFile: /data/kubelet/pki/kubelet.crt
tlsPrivateKeyFile: /data/kubelet/pki/kubelet.key

从 kube-apiserver 到 kubelet 的这些连接，在默认情况下，kube-apiserver 不会验证 kubelet 的服务端证书，这会使连接受到中间人攻击，并且在不受信任和/或公共网络上运行不安全。

这个区别于确保开启 kubelet 验证来自 kube-apiserver 请求，这个是 kubelet 验证 kube-apiserver 的证书是否有效。

同时还需在 kube-apiserver 上配置启用 kubelet 的 ca 证书，才可以生效：

--kubelet-certificate-authority

所有在 kube-apiserver 与 kubelet 通讯过程中，两个方向均存在证书验证，但 kubelet 的 https 一般自动生成，所以我们在使用过程中仅开启 kubelet 验证 kube-apiserver 的请求。

确保 kubelet 自动更新证书

kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
rotateCertificates: true

同步不可禁用 “RotateKubeletServerCertificate” 特性，当 kubelet 证书快过期时，会自动更新。

确保 kubelet 上报事件速率无限制

kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
eventRecordQPS: 0

用于限制收集事件的速率，默认为 5 设置得太低可能会导致相关事件不被记录，但是 0 的无限设置可能会导致kubelet上的拒绝服务，重要的是要捕获所有事件，而不是限制事件的创建。事件是安全信息和分析的重要来源，可确保使用事件数据持续监控您的环境。

Docs: 安全策略

Fri, 13 Oct 2023 09:12:10 +0800

简要概述

本节包含对 Kubernetes 集群环境安全的各种策略建议。

服务账户与RBAC

确保角色 cluster-admin 仅在需要时使用

Kubernetes 提供了一组默认的 RBAC 权限策略，其中 cluster-admin 允许用户访问任何资源以执行任何操作。

# kubectl get clusterrole cluster-admin -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
 annotations:
 rbac.authorization.kubernetes.io/autoupdate: "true"
 creationTimestamp: "2023-10-07T03:47:13Z"
 labels:
 kubernetes.io/bootstrapping: rbac-defaults
 name: cluster-admin
 resourceVersion: "23814649"
 uid: 49271b7e-1864-425b-b8dc-8b3900955d03
rules:
- apiGroups:
 - '*'
 resources:
 - '*'
 verbs:
 - '*'
- nonResourceURLs:
 - '*'
 verbs:
 - '*'
# ^C

获取哪些用户绑定了 cluster-admin 角色列表：

kubectl get clusterrolebindings -o=custom-columns=NAME:.metadata.name,ROLE:.roleRef.name,SUBJECT:.subjects[*].name

确保最小化权限访问 Secret 资源

通过以下指令审查：

kubectl get roles --all-namespaces -o yaml
kubectl get clusterroles -o yaml

TODO;

确保最小化通配符在 Roles 与 ClusterRoles 使用

同上。

确保最小化用户创建 Pod 的能力

在集群中创建 Pod 的能力可以提供许多权限提升的机会，例如为这些 Pod 分配特权服务帐户，或挂载可访问敏感数据的hostPaths（除非实施了Pod安全策略来限制这种访问）

通过以上方式审查。

确保访问 Kubernetes API 的工作负载都使用特定服务帐户

Kubernetes 提供了一个默认的服务帐户 “default”，当创建的 Pod 非分配特定的服务帐户，将会关联使用它。

如果需要从 Pod 访问 Kubernetes API，则应为该 Pod 创建一个特定的服务帐户，并将权限授予该服务帐户，不应使用默认服务帐户来授予应用程序的权限，这样可以更容易地进行审核和审查。

默认服务帐户应配置为不提供服务帐户令牌，也不具有任何明确的权限分配。

可通过以下两种方式关闭服务账户挂载：

在 Pod 模版中设置 “automountServiceAccountToken: false”

apiVersion: v1
kind: Pod
metadata:
 name: nginx
spec:
 containers:
 - image: registry.cn-hangzhou.aliyuncs.com/kube-image-repo/busybox:1.35.0
 name: nginx
 args:
 - /bin/sh
 - -c
 - "sleep 3600"
 automountServiceAccountToken: false

在创建 Service Account 中设置 “automountServiceAccountToken: false” 明确关闭

apiVersion: v1
kind: ServiceAccount
metadata:
 name: nginx
automountServiceAccountToken: false

如果未关闭，服务账户授权会被挂载在容器以下位置：

/var/run/secrets/kubernetes.io/serviceaccount # df -h
Filesystem Size Used Available Use% Mounted on
tmpfs 7.3G 12.0K 7.3G 0% /var/run/secrets/kubernetes.io/serviceaccount
......
/var/run/secrets/kubernetes.io/serviceaccount #
/var/run/secrets/kubernetes.io/serviceaccount # ls
ca.crt namespace token
/var/run/secrets/kubernetes.io/serviceaccount # ^C

确保不使用 system:masters 用户组

用户组 “system:masters” 是硬编码在 k8s 源码里面作为公知组，拥有集群管理员权限，避免在授权中直接使用。

# kubectl get clusterrolebinding cluster-admin -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 annotations:
 rbac.authorization.kubernetes.io/autoupdate: "true"
 creationTimestamp: "2023-10-07T03:47:13Z"
 labels:
 kubernetes.io/bootstrapping: rbac-defaults
 name: cluster-admin
 resourceVersion: "23814711"
 uid: 35e25988-3032-40a6-999f-34c78fd36963
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
 kind: Group
 name: system:masters
# ^C

确保限制使用 Bind Impersonate Escalate 权限

TODO;

Pod 安全策略

确保至少存在一个活跃的策略控制机制

Pod 安全策略由两种方式：

基于 k8s 树内的 Pod Security Admission 控制器实现；
基于外部的访问控制系统通过 validation 与 mutation webhooks 实现。

确保至少使用其中一种，如果没有的话，以下这些敏感操作将无法被限制：

特权容器；
挂载 hostPath。

确保没用使用特权容器

对以下三个属性设置为 “true” 开启特权容器运行。

spec.containers[].securityContext.privileged: true
spec.initContainers[].securityContext.privileged: true
spec.ephemeralContainers[].securityContext.privileged: true

这里启动一个 pod 为特权容器：

---
apiVersion: v1
kind: Pod
metadata:
 name: nginx
spec:
 containers:
 - image: registry.cn-hangzhou.aliyuncs.com/kube-image-repo/busybox:1.35.0
 name: nginx
 args:
 - /bin/sh
 - -c
 - "sleep 3600"
 securityContext:
 privileged: true

特权容器可以访问所有Linux内核功能和设备。以完全权限运行的容器几乎可以完成主机所能做的一切。此标志的存在是为了允许特殊的用例，如操作网络堆栈和访问设备。

确保最大限度地减少 hostPID 命名空间使用

通过添加 spec.hostPID: true 开启共享宿主进程命名空间，此时在容器内可以观察到宿主上所有运行的进程。

这是一个建议示列配置：

---
apiVersion: v1
kind: Pod
metadata:
 name: nginx
spec:
 containers:
 - image: registry.cn-hangzhou.aliyuncs.com/kube-image-repo/busybox:1.35.0
 name: nginx
 args:
 - /bin/sh
 - -c
 - "sleep 3600"
 hostPID: false

确保最大限度地减少 hostIPC 命名空间使用

通过添加 spec.hostIPC: true 开启共享宿主进程间通信命名空间，此时在容器内可以与宿主上其他进程通过管道、套接字、消息队列、信号量等通讯。

这是一个建议示列配置：

---
apiVersion: v1
kind: Pod
metadata:
 name: nginx
spec:
 containers:
 - image: registry.cn-hangzhou.aliyuncs.com/kube-image-repo/busybox:1.35.0
 name: nginx
 args:
 - /bin/sh
 - -c
 - "sleep 3600"
 hostICP: false

确保最大限度地减少 hostNetwork 命名空间使用

通过添加 spec.hostNetwork: true 开启共享宿主网络命名空间，此时在容器内使用同宿主网络IP、监听端口、数据流量等。

这是一个建议示列配置：

apiVersion: v1
kind: Pod
metadata:
 name: nginx
spec:
 containers:
 - image: registry.cn-hangzhou.aliyuncs.com/kube-image-repo/busybox:1.35.0
 name: nginx
 args:
 - /bin/sh
 - -c
 - "sleep 3600"
 hostNetwork: false

确保避免容器子进程可以获得比父进程更高的权限

在配置了 spec.securityContext.allowPrivilegeEscalation: true 情况下运行的容器有可能存在具有比父进程更高的权限。

这是一个建议示列配置：

apiVersion: v1
kind: Pod
metadata:
 name: nginx
spec:
 containers:
 - image: registry.cn-hangzhou.aliyuncs.com/kube-image-repo/busybox:1.35.0
 name: nginx
 args:
 - /bin/sh
 - -c
 - "sleep 3600"
 securityContext:
 allowPrivilegeEscalation: false

确保不使用 root 用户运行容器

容器可以以任何用户运行，虽然有运行时安全策略防护，在处于 root 运行的容器还是比普通用户更容器被攻破。

这是一个建议示列配置：

apiVersion: v1
kind: Pod
metadata:
 name: nginx
spec:
 containers:
 - image: registry.cn-hangzhou.aliyuncs.com/kube-image-repo/busybox:1.35.0
 name: nginx
 args:
 - /bin/sh
 - -c
 - "sleep 3600"
 securityContext:
 runAsNonRoot: false
 runAsUser: 65534

确保容器没有 NET_RAW 能力

TODO;

确保最小化 windows 容器没有 HostProcess 权限

TODO;

确保最小化使用 HostPath 挂载存储卷

通过 hostPath 的容器可以访问底层集群节点的文件系统，可以允许容器访问宿主上文件系统的任意区域，如：/etc/passwd。

所以必须存在策略限制挂载的路径。

确保避免使用 HostPorts 开放容器端口

主机端口将容器直接连接到宿主的网络，这可以绕过诸如网络策略之类的控制。

网络策略与 CNI

建议使用的 CNI 支持网络策略

TODO;

建议为命名空间定义默认网络策略

TODO;

kubectl get networkpolicy --all-namespaces

资源 Secrets 管理

建议机密数据作为文件挂载优先于环境变量

应用程序代码配置使用环境是相当常见，这将包括作为环境变量传递的任何机密值，这样任何有权访问日志的用户或应用都可以观察该值。

通过以下指令可以获取使用了环境变量：

kubectl get all -o jsonpath='{range .items[?(@..secretKeyRef)]} {.kind} {.metadata.name} {"\n"}{end}' -A

建议使用外部机密数据管理系统

如果您有更复杂的秘密管理需求，请考虑使用外部秘密存储和管理系统，而不是直接使用Kubernetes secrets。确保该解决方案需要身份验证才能访问机密，对机密的访问和使用进行审核，并对机密进行加密。某些解决方案还可以更容易地轮换机密。

因为默认 secrets 使用 base64 加密存储，这样只要集群管理人员拥有权限则可以对数据进行解密。

扩展准入控制器

建议使用 ImagePolicyWebhook 控制器

TODO;

https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook

一般公共策略

通过命名空间在资源之间创建管理边界

针对不同业务通过命名空间隔离，限制用户权限范围可以减少错误或恶意活动的影响。Kubernetes 命名空间允许您将创建的资源划分为逻辑命名的组，在一个命名空间中创建的资源可以对其他命名空间隐藏，您可以创建其他名称空间，并将资源和用户附加到这些名称空间。

默认存在以下命名空间：

“default” 当应用未主动配置部署的 “namespace” 时使用；
“kube-system” 集群系统应用；
“kube-node-lease” 维持主机心跳；
“kube-public” 集群公共信息；

例如在实际使用中可根据需求自定义了以下空间：

“cloud-monitor” 监控类业务部署；
“dcim-system” 运维类服务部署；
“biz-dev-uptime” 业务类开发部署；

确保启动 seccomp profile

TODO;

确保配置 Security Context 在 POD 与 Containers 中

TODO;

确保默认命名空间 default 没有正式应用

kubectl get pods -n default

Docs: 检测工具

Wed, 18 Oct 2023 10:35:26 +0800

简要概述

介绍通过 kube-bench 实现定时检测[CIS 基准]中的几个项目。

下载安装

二进制方式

跳转下载地址，根据不同目标选择。

容器化方式

官方地址：https://hub.docker.com/r/aquasec/kube-bench

docker pull docker.io/aquasec/kube-bench:latest
docker pull registry.cn-hangzhou.aliyuncs.com/kube-image-repo/kube-bench:latest

docker pull docker.io/aquasec/kube-bench:v0.6.18
docker pull registry.cn-hangzhou.aliyuncs.com/kube-image-repo/kube-bench:v0.6.18

运行检测示例

运行全部检测

./kube-bench \
 run \
 --config ./cfg/config.yaml \
 --config-dir ./cfg/

指定检测群组

./kube-bench \
 run \
 --config ./cfg/config.yaml \
 --config-dir ./cfg/ \
 --group "1.1"

指定检测步骤

./kube-bench \
 run \
 --config ./cfg/config.yaml \
 --config-dir ./cfg/ \
 --check "1.1.1,1.1.2"

跳过检测步骤

./kube-bench \
 run \
 --config ./cfg/config.yaml \
 --config-dir ./cfg/ \
 --group "1.1" --skip "1.1.19"

指定目标类型

./kube-bench \
 run \
 --config ./cfg/config.yaml \
 --config-dir ./cfg/ \
 --group "1.1" --skip "1.1.19" \
 --targets "master,node"

其中 targets 可取：[master node controlplane etcd policies]

写入结果至 pgsql

create database kube;
create role kube password 'oracle';
alter role kube with login;
grant all on database kube to kube;
grant all on all tables in schema public to kube;

export KUBE_BENCH_PGSQL_HOST=10.5.17.120
export KUBE_BENCH_PGSQL_USER=kube
export KUBE_BENCH_PGSQL_DBNAME=kube
export KUBE_BENCH_PGSQL_PASSWORD=oracle
export KUBE_BENCH_PGSQL_SSLMODE=disable

./kube-bench --config ./cfg/config.yaml --config-dir ./cfg/ --pgsql

检测 K8S 集群

控制节点
Worker 节点

以 daemonset 定时运行