1、Pod使用ServiceAccount

参考资料：https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-service-account/

  1. 这道题暂时没有真题截图，大致意思这样：
  2. 1、创建一个 SA（ServiceAccount）
  3. 2、修改已有 yaml 文件指定创建的 SA
  4. 3、删除当前命名空间中未绑定 Pod 的 SA

环境模拟：

  1. vi pod-nginx.yml 
  2. apiVersion: v1
  3. kind: Pod
  4. metadata:
  5.   name: web
  6. spec:
  7.   containers:
  8.   - image: nginx
  9.     name: web
  1. kubectl create sa test-sa
  2. kubectl create -f pod-nginx.yml

2、kube-bench

cks真题环境模拟 - 图1

cks真题环境模拟 - 图2cks真题环境模拟 - 图3

  1. 解读：使用 kube-bench 工具检查集群组件配置文件存在的问题与修复，并重启对应组件确保
  2. 新配置生效。

环境模拟：

api-server：

  1. vi /etc/kubernetes/manifests/kube-apiserver.yaml 
  2. ...
  3.     - --authorization-mode=Node,RBAC,AlwaysAllow
  4. ...

kubelet：

  1. vi /var/lib/kubelet/config.yaml    
  2. ...
  3. authentication:
  4.   anonymous:
  5.     enabled: true
  6. ...
  7. authorization:
  8.   mode: Webhook,AlwaysAllow
  9. ...

etcd：

  1. vi /etc/kubernetes/manifests/etcd.yaml 
  2. ...
  3.     - --client-cert-auth=false
  4. ...

重启kubelet

  1. systemctl restart kubelet

3、网络策略 （重要）

参考资料 ： https://kubernetes.io/zh/docs/concepts/services-networking/network-policies/

cks真题环境模拟 - 图4

  1. 解读：在 testing 命名空间创建一个名为 denypolicy 的网络策略。拒绝所有 Ingress 和 Egress 流量。将网络策略应用到 testing 命名空间中的所有 pod。

环境模拟：

  1. kubectl create namespace testing
  3. kubectl run testing-pod-1 --image=busybox -n testing --command -- sleep 24h
  4. kubectl run testing-pod-2 --image=busybox -n testing --command -- sleep 24h
  6. kubectl run testing-pod --image=busybox --command -- sleep 24h

4、Pod安全策略（PSP）（重要）

参考资料：https://kubernetes.io/zh/docs/concepts/policy/pod-security-policy/

cks真题环境模拟 - 图5

  1. 解读：
  2. 1. 创建一个名为 restrict-policy 的 PodSecurityPolicy，防止创建特权 Pod
  3. 2. 创建一个名为 restrict-access-role 的 ClusterRole 能够使用 PSP restrict-policy
  4. 3. 在 staging 命名空间创建一个名为 psp-denial-sa 的 ServiceAccount
  5. 4. 最后，创建一个名为 dany-access-bind 的 ClusterRoleBinding，绑定 ClusterRolerestrict-access-role 到 ServiceAccount psp-denial-sa

环境模拟：

/etc/kubernetes/manifests/kube-apiserver.yaml

  1.     - --enable-admission-plugins=NodeRestriction

pod-security-policy.yml 

  1. apiVersion: policy/v1beta1
  2. kind: PodSecurityPolicy
  3. metadata:
  4.   name: restrict-policy
  5. spec:
  6.   privileged: true
  7.   seLinux:
  8.     rule: RunAsAny
  9.   supplementalGroups:
  10.     rule: RunAsAny
  11.   runAsUser:
  12.     rule: RunAsAny
  13.   fsGroup:
  14.     rule: RunAsAny
  15.   volumes:
  16.   - '*'

cluster-role.yml

  1. apiVersion: rbac.authorization.k8s.io/v1
  2. kind: ClusterRole
  3. metadata:
  4.   creationTimestamp: null
  5.   name: restrict-access-role
  6. rules:
  7. - apiGroups:
  8.   - policy
  9.   resourceNames:
  10.   - restrict-policy
  11.   resources:
  12.   - podsecuritypolicies
  13.   verbs:
  14.   - use

service-account.yml

  1. apiVersion: v1
  2. kind: ServiceAccount
  3. metadata:
  4.   creationTimestamp: null
  5.   name: psp-denial-sa
  6.   namespace: staging

cluster-role-binding.yml

  1. apiVersion: rbac.authorization.k8s.io/v1
  2. kind: ClusterRoleBinding
  3. metadata:
  4.   creationTimestamp: null
  5.   name: dany-access-bind
  6. roleRef:
  7.   apiGroup: rbac.authorization.k8s.io
  8.   kind: ClusterRole
  9.   name: restrict-access-role
  10. subjects:
  11. - kind: ServiceAccount
  12.   name: psp-denial-sa
  13.   namespace: staging
  1. kubectl create namespace staging
  2. kubectl create -f 4-PodSecurityPolicy/

5、RBAC

cks真题环境模拟 - 图6

  1. 解读：
  2. 1. 在 db 命名空间存在一个名为 web-pod 的 Pod
  3. 2. 编辑该 Pod 绑定的 ServiceAccount service-account-web Role，只允许对 Endpoints 资源类型执行 get 操作
  4. 3. 在 db 命名空间创建一个名为 role-2 的 Role，该角色只允许对 namespaces 资源类型执行delete 操作
  5. 4. 创建一个名为 role-2-binding 的 RoleBinding，绑定到 ServiceAccount

环境模拟：

role-1

  1. apiVersion: rbac.authorization.k8s.io/v1
  2. kind: Role
  3. metadata:
  4.   namespace: db
  5.   name: role-1
  6. rules:
  7. - apiGroups: [""]
  8.   resources: ["pods", "services","deployments","endpoints"]
  9.   verbs: ["get", "list","delete","update"]

rolebinding

  1. kubectl create rolebinding role-1-binding --role=role-1 --serviceaccount=db:service-account-web -n db

web-pod

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: web-pod
  5.   namespace: db
  6. spec:
  7.   containers:
  8.   - image: nginx
  9.     name: web-pod
  10.   serviceAccount: service-account-web
  11.   serviceAccountName: service-account-web

执行：

  1. kubectl create namespace db
  2. kubectl create serviceaccount service-account-web -n db

6、日志审计（重要）

参考资料：https://kubernetes.io/zh/docs/tasks/debug-application-cluster/audit/

cks真题环境模拟 - 图7

  1. 解读：在集群启用审计，并确保：
  2.   日志路径为 /var/log/kubernetes/audit-logs.txt
  3.   日志文件保留 10 天
  4.   最多保留 2 个日志文件
  5. 基本策略在/etc/kubernetes/logpolicy/sample-policy.yaml 文件（该文件在 master 节点上）中提供，它指定了不记录的内容编辑和扩展基本策略：
  6.   命名空间在 RequestResponse 级别更改
  7.   PV 的请求内容在 front-apps 命名空间发生了更改
  8.   Configmap 和 secret 在所有命名空间 Metadata 级别更改

环境模拟：

7、Secret

参考资料：https://kubernetes.io/zh/docs/concepts/configuration/secret/

cks真题环境模拟 - 图8

  1. 解读：
  2. 1、在 istio-system 命名空间存在一个名为 db1-test 的 secret，将 username 字段保存到文件名为/home/candidate/user.txt 和 password 字段保存到文件名为/home/candidate/pass.txt
  3. 注：文件需要自己创建
  4. 2、在 istio-system 命名空间创建一个名为 db2-test 的 secret，内容如下：
  5. username: production-instance
  6. password: KvLftKgs4aVH
  7. 最后，创建一个新的 Pod，可以通过 volume 方式访问 secret 内容。

环境模拟：

  1. kubectl create namespace istio-system 
  2. kubectl create secret generic db1-test --from-literal=username=production-instance --from-literal=password=KvLftKgs4aVH -n istio-system
  4. mkdir /home/candidate/

8、Dockerfile和Deployment优化

cks真题环境模拟 - 图9

环境模拟：

Dockerfile

  1. FROM ubuntu:16.04
  2. MAINTAINER "Geray <xxx@qq.com>"
  4. RUN     /bin/echo 'root:123456' |chpasswd
  5. RUN     useradd runoob
  6. RUN     /bin/echo 'runoob:123456' |chpasswd
  7. RUN     /bin/echo -e "LANG=\"en_US.UTF-8\"" >/etc/default/local
  8. EXPOSE  22
  9. EXPOSE  80
  10. USER root
  11. CMD     /usr/sbin/sshd -D

Deployment

  1. apiVersion: apps/v1
  2. kind: Deployment
  3. metadata:
  4.   name: web-test
  5. spec:
  6.   replicas: 1
  7.   selector:
  8.     matchLabels:
  9.       app: web-test
  10.   template:
  11.     metadata:
  12.       labels:
  13.         app: web-test
  14.     spec:
  15.       containers:
  16.       - image: nginx
  17.         name: nginx
  18.         securityContext:
  19.           capabilities:
  20.             add: ["NET_BIND_SERVICE"]
  21.           privileged: true

9、沙箱运行容器gVisor

参考资料：https://kubernetes.io/zh/docs/concepts/containers/runtime-class/

cks真题环境模拟 - 图10

  1. 描述：这个集群使用 containerd 作为 CRI 运行时。Containerd 的默认运行时处理程序是runc，containerd 也支持额外的运行时处理程序 runsc（gVisor）
  3. 解读：创建一个名为 untrusted 的 RuntimeClass，使用准备好的运行时处理程序 runsc。
  4. 更新 server 命名空间中的所有 Pod 使其在 gVisor 上运行。

环境模拟：

1、使用containerd作为k8s容器运行时

1）准备配置

  1. cat > /etc/sysctl.d/99-kubernetes-cri.conf << EOF
  2. net.bridge.bridge-nf-call-iptables = 1
  3. net.ipv4.ip_forward = 1
  4. net.bridge.bridge-nf-call-ip6tables = 1
  5. EOF
  6. sysctl --system

2）安装containerd容器引擎

CentOS

  1. cd /etc/yum.repos.d
  2. wget http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
  3. yum install -y containerd.io

Ubuntu

  1. apt-get install -y containerd.io

3）修改配置文件

  • pause镜像地址
  • Cgroup驱动改为systemd
  • 增加runsc容器运行时
  • 配置docker镜像加速器
  1. mkdir -p /etc/containerd
  2. containerd config default > /etc/containerd/config.toml
  3. vi /etc/containerd/config.toml
  4. ...
  5.   [plugins."io.containerd.grpc.v1.cri"] # 下面修改
  6.     sandbox_image = "registry.aliyuncs.com/google_containers/pause:3.2"
  8. ...
  9.           [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]# 下面增加
  10.             SystemdCgroup = true
  11. ...
  12.           [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runsc]
  13.             runtime_type = "io.containerd.runsc.v1"
  14.         [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"] # 上面增加两行
  15.           endpoint = ["https://b9pmyelo.mirror.aliyuncs.com"] # 修改为阿里云的地址
  17. ...
  18. systemctl restart containerd

4）配置kubelet使用containerd

** systemctl cat kubelet**查看EnvironmentFile

CentOS：/etc/sysconfig/kubelet

Ubuntu：/etc/default/kubelet

  1. vi /etc/default/kubelet # 使用Ubuntu系统
  2. KUBELET_EXTRA_ARGS=--container-runtime=remote --container-runtime-endpoint=unix:///run/containerd/containerd.sock --cgroup-driver=systemd
  3. systemctl restart kubelet

5）验证

  1. kubectl get node -o wide

问题解决：crictl info异常

  1. crictl info
  2. NAME:
  3.    crictl info - Display information of the container runtime
  5. USAGE:
  6.    crictl info [command options] [arguments...]
  8. OPTIONS:
  9.    --output value, -o value  Output format, One of: json|yaml (default: "json")
  11. FATA[0010] failed to connect: failed to connect: context deadline exceeded
  1. crictl config runtime-endpoint /run/containerd/containerd.sock

问题解决：calico节点pod无法启动（ip被占用）

  1. kubectl logs calico-node-pj89k -n kube-system
  2. ...
  3. 2021-12-23 02:42:45.754 [WARNING][12] startup/startup.go 1074: Calico node 'k8s-master-1' is already using the IPv4 address 172.18.0.1.
  4. ....
  • IPv4地址已经被占用
  1. ip a | grep 172.18.0.1
  2.     inet 172.18.0.1/16 brd 172.18.255.255 scope global br-ae62d50bbde3
  4. docker network ls | grep ae62d50bbde3
  5. ae62d50bbde3   harbor_harbor   bridge    local
  • 可以看到docker已经自动生成改网卡，使用docker删除这个网卡
  1. docker network rm ae62d50bbde3
  2. Error response from daemon: error while removing network: network harbor_harbor id ae62d50bbde3d1547c9529127c2dd1a90abdd77357a8f826f3c417a3089c169b has active endpoints
  • 无法删除，已经和harbor进行关联（之前装过harbor，停止harbor）
  1. docker-compose down -v
  2. # 再次查看发现已经释放了，pod并成功运行
  3. ip a | grep 172.18.0.1
  4. docker network ls | grep ae62d50bbde3

问题处理：所有pod无法分配到k8s-node-1节点

  1.   Warning  FailedScheduling  30s (x2 over 32s)  default-scheduler  0/2 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 1 node(s) had taint {node.kubernetes.io/disk-pressure: }, that the pod didn't tolerate.
  • 可以看到不可调度
  1. kubectl describe node k8s-node-1 | grep -A4 Taint
  2. Taints:             node.kubernetes.io/disk-pressure:NoSchedule
  3. Unschedulable:      false
  4. ...
kubelet 依据节点上观测到的 imagefs.available、imagefs.inodesFree、nodefs.available 和 nodefs.inodesFree(仅 Linux) 来判断磁盘压力。 用观测值对比 kubelet 设置的阈值，以确定节点状态和污点是否可以被添加/移除。

这是由于我的节点磁盘空间使用率超过了kubelet的阈值导致服务被调度

cks真题环境模拟 - 图11

2、准备runtime-class.yaml文件

runtime-class.yaml

  1. apiVersion: node.k8s.io/v1
  2. kind: RuntimeClass # RuntimeClass 是一个集群层面的资源
  3. metadata:
  4.   name: untrusted  # 用来引用 RuntimeClass 的名字
  5. handler: runsc  # 对应的 CRI 配置的名称（运行时接口）

3、执行

  1. kubectl create namespace server
  3. kubectl create -f runtime-class.yaml
  5. kubectl create deployment web --image=nginx -n server

10、删除启用的特权pod

参考资料：https://kubernetes.io/zh/docs/concepts/security/pod-security-standards/

cks真题环境模拟 - 图12

  1. 解读：检查在 production 命名空间运行的 Pod，并删除任何不是非无状态（有状态）或非不可变（可变）的 Pod
  2. 以下是对无状态和不可变的解释：
  3.  在容器中存储数据的 Pod 视为非无状态（不用担心容器数据持久化）
  4.  启用特权的 Pod 都视为潜在的非无状态和非不可变

环境模拟：

这道题应该包含存在挂载（数据卷- 保留readOnly）和特权的pod

  • 检查是否存在volumeMount 和 privileged: true
  1. kubectl create namespace production
  3. ---
  4. apiVersion: v1
  5. kind: Pod
  6. metadata:
  7.   name: web1
  8.   namespace: production
  9. spec:
  10.   containers:
  11.   - image: nginx
  12.     name: web1
  13.     securityContext:
  14.       privileged: true
  15. ---
  16. apiVersion: v1
  17. kind: Pod
  18. metadata:
  19.   name: web2
  20.   namespace: production
  21. spec:
  22.   containers:
  23.   - image: nginx
  24.     name: web2
  25.     securityContext:
  26.       privileged: true
  27. ---
  28. apiVersion: v1
  29. kind: Pod
  30. metadata:
  31.   name: web3
  32.   namespace: production
  33. spec:
  34.   containers:
  35.   - image: nginx
  36.     name: web3
  38. kubectl create -f web.yml

11、网络策略 （重要）

参考资料 ： https://kubernetes.io/zh/docs/concepts/services-networking/network-policies

cks真题环境模拟 - 图13

  1. 解读：创建一个名为 pod-restriction 的网络策略，以限制命名空间 dev-team 中 products-service Pod。
  2. 只允许以下 Pod 连接 products-service Pod：
  3.  qa 命名空间中的 Pod
  4.  Pod 标签为 environment:testing，在所有命名空间

环境模拟：

  1. kubectl create namespace dev-team --labels="environment=staging"
  2. kubectl create namespace qa --labels="name=qa"
  4. kubectl run products-service --image=nginx -ndev-team
  6. kubectl -n qa run test --image=busybox --command -- sleep 24h
  7. kubectl run test1 --image=busybox --labels="environment=testing" --command -- sleep 24h
  8. kubectl run test2 --image=busybox --command -- sleep 24h

network-policy.yaml

  1. apiVersion: networking.k8s.io/v1
  2. kind: NetworkPolicy
  3. metadata:
  4.   name: pod-restriction
  5.   namespace: dev-team
  6. spec:
  7.   podSelector:
  8.     matchLabels:
  9.       environment: staging
  10.   policyTypes:
  11.   - Ingress
  12.   ingress:
  13.   - from:
  14.     - namespaceSelector:
  15.         matchLabels:
  16.           name: qa
  17.   - from: # 这里的from可有可无
  18.     - namespaceSelector: {} # 这个namespace是必须的
  19.       podSelector:
  20.         matchLabels:
  21.           environment: testing

12、ImagePolicyWebhook （重要）

参考资料 ： https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook

cks真题环境模拟 - 图14

  1. 提示：必须在集群 master 节点完成任务，其中包含的所有服务和文件已准备好。
  2. 解读：在/etc/kubernetes/epconfig 目录下有一个不完整的配置和一个功能容器镜像扫描器HTTPS 端点：https://acme.local:8082/image_policy
  3. 1. 启用准入控制插件
  4. 2. 验证控制配置并将其更改为默认拒绝。
  5. 3. 修改配置文件，指向正确的 HTTPS 端点最后，尝试部署易受供攻击的资源来测试配置是否有效。/root/KSSC00202/ulnerable-manifest.yml
  6. 查看容器扫描日志：/var/log/imagepolicy/roadrunner.log

环境模拟：暂时未模拟

1、插件

  • 方便起见，使用YAML代替json
  1. vi /etc/kubernetes/manifests/kube-apiserver.yaml
  2. …
  3. - --enable-admission-plugins=NodeRestriction
  4. #- --admission-control-config-file=/etc/kubernetes/epconfig/admission_configuration.yaml
  6. # 注释或删除HostPath数据卷在宿主机/etc/kubernetes/image-policy目录的挂载信息

2、验证配置文件

admission_configuration.yaml

  1. cd /etc/kubernetes/epconfig
  2. vi adminssion_configuration.yaml
  3. apiVersion: apiserver.config.k8s.io/v1
  4. kind: AdmissionConfiguration
  5. plugins:
  6. - name: ImagePolicyWebhook
  7.   configuration:
  8.     imagePolicy:
  9.       kubeConfigFile: /etc/kubernetes/epconfig/connect_webhook.yaml # 连接镜像策略服务器配置文件
  10.       allowTTL: 50 # 控制批准请求的缓存时间（s）
  11.       denyTTL: 50 # 控制拒绝请求的缓存时间（s）
  12.       retryBackoff: 500 # 控制重试间隔（ms）
  13.       defaultAllow: true # 确定Webhook后端实效的行为

3、kubeconfig配置文件

kubeconfig.yaml

类似于kubectl config命令生成的~/.kube/conf，直接拷贝改文件至/etc/kubernetes/epconfig/connect_webhook.yaml并删除其中证书信息，并修改为如下

  1. cd /etc/kubernetes/epconfig/
  2. vi connect_webhook.yaml
  3. apiVersion: v1
  4. clusters:
  5. - cluster:
  6.     certificate-authority-data: /etc/kubernetes/epconfig/webhook.pem # 数字证书，用于验证远程服务
  7.     server: https://192.168.6.31:8080/image_policy # 镜像策略服务器地址，必须是https
  8.   name: kubernetes
  9. contexts:
  10. - context:
  11.     cluster: webhook
  12.     user: apiserver
  13.   name: kubernetes-admin@kubernetes
  14. current-context: webhook
  15. kind: Config
  16. preferences: {}
  17. users:
  18. - name: apiserver
  19.   user:
  20.     client-certificate-data:  /etc/kubernetes/epconfig/apiserver-client.pem # webhook准入控制器使用的证书
  21.     client-key-data: /etc/kubernetes/epconfig/apiserver-client-key.pem # 对应私钥证书
  • 注：涉及的证书文件，下一步生成，拷贝到该文件中对应路径

4、自签证书配置

image-policy-certs.sh

  1. cat > ca-config.json <<EOF
  2. {
  3.   "signing": {
  4.     "default": {
  5.       "expiry": "87600h"
  6.     },
  7.     "profiles": {
  8.       "kubernetes": {
  9.          "expiry": "87600h",
  10.          "usages": [
  11.             "signing",
  12.             "key encipherment",
  13.             "server auth",
  14.             "client auth"
  15.         ]
  16.       }
  17.     }
  18.   }
  19. }
  20. EOF
  22. cat > ca-csr.json <<EOF
  23. {
  24.     "CN": "kubernetes",
  25.     "key": {
  26.         "algo": "rsa",
  27.         "size": 2048
  28.     },
  29.     "names": [
  30.         {
  31.             "C": "CN",
  32.             "L": "Beijing",
  33.             "ST": "Beijing"
  34.         }
  35.     ]
  36. }
  37. EOF
  39. cfssl gencert -initca ca-csr.json | cfssljson -bare ca -
  41. cat > webhook-csr.json <<EOF
  42. {
  43.   "CN": "webhook",
  44.   "hosts": [
  45.    "192.168.6.31" 
  46.    ],
  47.   "key": {
  48.     "algo": "rsa",
  49.     "size": 2048
  50.   },
  51.   "names": [
  52.     {
  53.       "C": "CN",
  54.       "L": "BeiJing",
  55.       "ST": "BeiJing"
  56.     }
  57.   ]
  58. }
  59. EOF
  61. cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes webhook-csr.json | cfssljson -bare webhook
  63. cat > apiserver-client-csr.json <<EOF
  64. {
  65.   "CN": "apiserver",
  66.   "hosts": [],
  67.   "key": {
  68.     "algo": "rsa",
  69.     "size": 2048
  70.   },
  71.   "names": [
  72.     {
  73.       "C": "CN",
  74.       "L": "BeiJing",
  75.       "ST": "BeiJing"
  76.     }
  77.   ]
  78. }
  79. EOF
  81. cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes apiserver-client-csr.json | cfssljson -bare apiserver-client
  • -u root 挂载时需要使用root权限（生产环境将证书直接打到镜像，不会涉及改问题）
  • PYTHONUNBUFFERED=1 关闭Python缓存区

5、webhook镜像策略容器（使用docker创建容器测试，k8s部署目前无法访问）

  1. docker pull lizhenliang/image-policy-webhook
  2. docker pull geray/image-policy-webhook:latest
  4. # 一下是docker测试用例，模拟考试环境使用deployment
  5. docker run -d -u root --name=image-policy-webhook \
  6. -v $PWD/webhook.pem:/data/www/webhook.pem \
  7. -v $PWD/webhook-key.pem:/data/www/webhook-key.pem \
  8. -e PYTHONUNBUFFERED=1 -p 8080:8080 \
  9. geray/image-policy-webhook:latest

ulnerable-manifest.yml 

  1. apiVersion: apps/v1
  2. kind: Deployment
  3. metadata:
  4.   labels:
  5.     app: image-policy
  6.   name: image-policy
  7. spec:
  8.   replicas: 1
  9.   selector:
  10.     matchLabels:
  11.       app: image-policy
  12.   template:
  13.     metadata:
  14.       labels:
  15.         app: image-policy
  16.     spec:
  17.       containers:
  18.       - image: geray/image-policy-webhook:latest
  19.         name: image-policy-webhook
  20.         env:
  21.         - name: PYTHONUNBUFFERED
  22.           value: "1"
  23.         volumeMounts:
  24.         - mountPath: /data/www/webhook.pem
  25.           name: webhook
  26.           subPath: webhook.pem # 只挂载改文件
  27.         - mountPath: /data/www/webhook-key.pem
  28.           name: webhook-key
  29.           subPath: webhook-key.pem
  30.       volumes:
  31.         - name: webhook # 挂载时引用的名称
  32.           configMap:
  33.             name: webhook
  34.             #defaultMode: 0777 # 挂载文件权限
  35.             items:
  36.             - key: webhook # configmap名称
  37.               path: webhook.pem
  38.         - name: webhook-key
  39.           configMap:
  40.             name: webhook
  41.             items:
  42.             - key: key
  43.               path: webhook-key.pem

执行

  1. chmod +x image-policy-certs.sh && ./image-policy-certs.sh
  3. cp /etc/kubernetes/epconfig/apiserver-client.pem
  4. cp /etc/kubernetes/epconfig/apiserver-client-key.pem
  5. cp /etc/kubernetes/epconfig/webhook.pem
  7. kubectl create configmap webhook --from-file=webhook="/root/cks/12-networkpolicywebhook/tls/webhook.pem" --from-file=key="/root/cks/12-networkpolicywebhook/tls/webhook-key.pem"
  9. kubectl create -f ulnerable-manifest.yml
  11. kubectl expose deployment image-policy --port=8080 --target-port=8080  --type=NodePort

13、Trivy扫描镜像安全漏洞

cks真题环境模拟 - 图15

  1. 解读：对 kamino 命名空间中 pod 使用 Trivy 工具扫描镜像安全漏洞。查找具有高危或严重漏洞的镜像，并删除使用这些镜像的 Pod。
  2. 注：Trivy 已经预装集群的 master 节点，工作节点不可用。

环境模拟：

  1. kubectl create namespace kamino
  3. kubectl run web-test --image=nginx
  4. kubectl run test --image=busybox --command -- sleep 24h

14、AppArmor

参考资料：https://kubernetes.io/zh/docs/tutorials/clusters/apparmor

cks真题环境模拟 - 图16

  1. 解读：在集群的工作节点上，执行下面准备好的配置文件/etc/apparmor.d/nginx_apparmor编辑准备好的清单文件/home/candidate/KSSH00401/nginx-deploy.yaml 应用于 AppArmor 文件。
  2. 最后，在 Pod 中应用 apparmor 策略文件。

环境模拟：

15、启用kubernetes API认证

  1. 描述：kubeadm 创建的集群的 Kubernetes API 服务器，出于测试目的，临时配置为允许未经身份验证和未经授权的访问，授予匿名用户集群管理员访问权限。
  2. 要求：重新配置集群的 Kubernetes API 服务器以确保只允许经过身份验证和授权的 API 请求。
  3.  使用授权模式 Node、RBAC 和准入控制器 NodeRestriction
  4.  删除名为 system:anonymous 的 ClusterRoleBinding

环境模拟：

  1. vi /etc/kubernetes/manifests/kube-apiserver.yaml
  2.  - kube-apiserver
  3.  - --authorization-mode=Node,RBAC # 只保留这两个
  4. - --enable-admission-plugins=NodeRestriction # 只保留这一个
  6. systemctl restart kubelet
  8. # 删除角色绑定
  9. kubectl delete clusterrolebinding system:anonymous