K8S认证安全工程师(CKS)考试（最新版，实测可靠）

k8s的全部考试答案，亲测可靠，博主CKA,CKS已过，接待交流。（求个关注吧）

1、kube-bench 修复不安全项

Context
针对 kubeadm 创建的 cluster 运行 CIS 基准测试工具时，发现了多个必须立即办理的问题。
Task
通过设置修复所有问题并重新启动受影响的组件以确保新的设置收效。
修复针对 API 服务器发现的所有以下违规行为：
1.2.7 Ensure that the --authorization-mode argument is not set to AlwaysAllow FAIL
1.2.8 Ensure that the --authorization-mode argument includes Node FAIL
1.2.9 Ensure that the --authorization-mode argument includes RBAC FAIL
1.2.18 Ensure that the --insecure-bind-address argument is not set FAIL （v1.28 考题中这项没给出，但最好也检查一下，模拟环境是里需要改的）
修复针对 kubelet 发现的所有以下违规行为：
Fix all of the following violations that were found against the kubelet:
4.2.1 Ensure that the anonymous-auth argument is set to false FAIL
4.2.2 Ensure that the --authorization-mode argument is not set to AlwaysAllow FAIL
留意：尽可能使用 Webhook 身份验证/授权。
修复针对 etcd 发现的所有以下违规行为：
Fix all of the following violations that were found against etcd:
2.2 Ensure that the --client-cert-auth argument is set to true FAIL
模拟环境里，初始化这道题的脚本为 kube-bench.sh

1. candidate@node01:~$ ssh master01
2. candidate@master01:~$ sudo -i
3. root@master01:~$ sh kube-bench.sh //模拟这道题的初始环境
4. root@master01:~$ mkdir bak1
5. root@master01:~$ cp /etc/kubernetes/manifests/kube-apiserver.yaml bak1/
6. root@master01:~$ cp /etc/kubernetes/manifests/etcd.yaml bak1/
7. root@master01:~$ cp /var/lib/kubelet/config.yaml bak1/

复制代码

1. root@master01:~$ vim /etc/kubernetes/manifests/kube-apiserver.yaml
2. - --authorization-mode=Node,RBAC
3. #删除 insecure-bind-address。实际考试中，有可能本来就没写这行。
4. - --insecure-bind-address=0.0.0.0
6. root@master01:~$ vim /var/lib/kubelet/config.yaml
7. # anonymous 应该为 false，webhook 应该为 true。
8. anonymous:
9. enabled: false #将 true 改为 false
10. webhook:
11. enabled: true #修改为 true。
13. authorization: #修改 authorization 下的
14. mode: Webhook #改为 Webhook
16. root@master01:~$ vim /etc/kubernetes/manifests/etcd.yaml
17. - --client-cert-auth=true #修改为 true
19. root@master01:~$ systemctl daemon-reload
20. root@master01:~$ systemctl restart kubelet
21. root@master01:~$ kubectl get pod -A # 确保所有的 pod 都是 Running
22. exit,exit

复制代码

2、Pod 指定 ServiceAccount

Context
您组织的安全战略包罗：
ServiceAccount 不得主动挂载 API 根据
ServiceAccount 名称必须以“-sa”结尾
清单文件 /cks/sa/pod1.yaml 中指定的 Pod 由于 ServiceAccount 指定错误而无法调治。
请完成一下项目：
Task
在现有 namespace qa 中创建一个名为 backend-sa 的新 ServiceAccount，确保此 ServiceAccount 不主动挂载 API 根据。
使用 /cks/sa/pod1.yaml 中的清单文件来创建一个 Pod。
最后，清理 namespace qa 中任何未使用的 ServiceAccount。
1 创建 ServiceAccount

1. ## 搜sa 全称configure-service-account
2. candidate@node01:~$ vim qa-ns.yaml
3. apiVersion: v1
4. kind: ServiceAccount
5. metadata:
6. name: backend-sa #修改 name
7. namespace: qa #注意添加 namespace
8. automountServiceAccountToken: false #修改为 false，表示不自动挂载 secret
9. candidate@node01:~$ kubectl apply -f qa-ns.yaml
10. candidate@node01:~$ kubectl get sa -n qa
11. NAME         SECRETS   AGE
12. backend-sa   0         58s

复制代码

2 创建 Pod 使用该 ServiceAccount

1. candidate@node01:~$ vi /cks/sa/pod1.yaml
2. ……
3. metadata:
4. name: backend
5. namespace: qa #注意命名空间是否对
6. spec:
7. serviceAccountName: backend-sa # 没有则添加一行，有则修改这一行
8. containers:
9. ……
10. candidate@node01:~$ kubectl apply -f /cks/sa/pod1.yaml
11. candidate@node01:~$ kubectl get pod -n qa
12. NAME      READY   STATUS    RESTARTS      AGE
13. backend   1/1     Running   0             8s

复制代码

3 删除没有使用的 ServiceAccount

1. # 查看所有 sa，下图可以看到一共有 3 个 sa。
2. candidate@node01:~$ kubectl get sa -n qa
3. # 查看已经在用的 sa，可以看到 default 和 backend-sa 都已经使用了。
4. candidate@node01:~$ kubectl get pod -n qa -o yaml | grep -i serviceAccountName
5. # 删除不用的 sa
6. candidate@node01:~$ kubectl delete sa test01 -n qa

复制代码

3、默认网络战略

Context
一个默认拒绝（default-deny）的 NetworkPolicy 可避免在未界说任何其他 NetworkPolicy 的 namespace 中意外公开 Pod。
Task
为所有类型为 Ingress+Egress 的流量在 namespace testing 中创建一个名为 denypolicy 的新默认拒绝 NetworkPolicy。 此新的 NetworkPolicy 必须拒绝 namespace testing 中的所有的 Ingress + Egress 流量。 将新创建的默认拒绝 NetworkPolicy 应用与在 namespace testing 中运行的所有 Pod。
你可以在 /cks/net/p1.yaml 找到一个模板清单文件。

1. ## 搜networkpolicy
2. candidate@node01:~$ vi /cks/net/p1.yaml
3. apiVersion: networking.k8s.io/v1
4. kind: NetworkPolicy
5. metadata:
6. name: denypolicy #修改 name
7. namespace: testing #注意添加 namespace
8. spec:
9. podSelector: {}
10. policyTypes:
11. - Ingress
12. - Egress #根据题目要求保留
13. candidate@node01:~$ kubectl apply -f /cks/net/p1.yaml
14. candidate@node01:~$ kubectl describe networkpolicy denypolicy -n testing

复制代码

4、RBAC - RoleBinding

Context
绑定到 Pod 的 ServiceAccount 的 Role 授予过分宽松的权限。完成以下项目以减少权限集。
Task
一个名为 web-pod 的现有 Pod 已在 namespace db 中运行。
编辑绑定到 Pod 的 ServiceAccount service-account-web 的现有 Role，仅允许只对 services 类型的资源实行 get 操作。 在 namespace db 中创建一个名为 role-2 ，并仅允许只对 namespaces 类型的资源实行 delete 操作的新 Role。 创建一个名为 role-2-binding 的新 RoleBinding，将新创建的 Role 绑定到 Pod 的 ServiceAccount。
留意：请勿删除现有的 RoleBinding。

1. ## 搜RBAC
2. candidate@node01:~$ kubectl describe rolebindings -n db
3. candidate@node01:~$ kubectl edit role role-1 -n db
4. ……
5. rules: #模拟环境里要删除掉 null，然后添加以下内容。考试时，要根据实际情况修改。
6. - apiGroups: [""]
7. resources: ["services"]
8. #对 services 资源 get 操作权限。还可能会考对 endpoints 资源 list 的操作权限，或对 namespace 的 update 权限。
9. verbs: ["get"]
10. #这里也是要根据题目实际的要求写，比如题目要求 watch 权限，则这里就将 get 改成 watch。
11. candidate@node01:~$ kubectl create role -h
12. candidate@node01:~$ kubectl create role role-2 --verb=delete --resource=namespaces -n db
13. ## 记住 --verb 是权限，可能考 delete 或者 update 等 --resource 是对象，可能考 namespaces 或者 persistentvolumeclaims 等。
14. candidate@node01:~$ kubectl create rolebinding -h
15. candidate@node01:~$ kubectl create rolebinding role-2-binding --role=role-2 --serviceaccount=db:service-account-web -n db
16. candidate@node01:~$ kubectl describe rolebindings -n db
17. candidate@node01:~$ kubectl describe role -n db

复制代码

5、日志审计 log audit

Task
在 cluster 中启用审计日志。为此，请启用日志后端，并确保：

• 日志存储在 /var/log/kubernetes/audit-logs.txt
  
• 日志文件能保存 10 天
  
• 最多保存 2 个旧审计日志文件
  

/etc/kubernetes/logpolicy/sample-policy.yaml 提供了根本战略。它仅指定不记录的内容。
留意：根本战略位于 cluster 的 master 节点上。
编辑和扩展根本战略以记录：

• RequestResponse 级别的 persistentvolumes 更改
  
• namespace front-apps 中 configmaps 更改的请求体
  
• Metadata 级别的所有 namespace 中的 ConfigMap 和 Secret 的更改
  

别的，添加一个全方位的规则以在 Metadata 级别记录所有其他请求。
留意：不要忘记应用修改后的战略。
模拟环境里，初始化这道题的脚本为 log-audit.sh
设置审计战略

1. candidate@node01:~$ ssh master01
2. candidate@master01:~$ sudo -i
3. root@master01:~$ sh log-audit.sh
4. root@master01:~$ cp /etc/kubernetes/logpolicy/sample-policy.yaml bak1/
5. root@master01:~$ vim /etc/kubernetes/logpolicy/sample-policy.yaml
6. # 搜audit
7. rules:
8. # namespaces changes at RequestResponse level
9. - level: RequestResponse
10. resources:
11. - group: ""
12. resources: ["persistentvolumes"] #根据题目要求修改，比如题目要求的是 namespaces。
13. #the request body of persistentvolumes/pods changes in the namespace front-apps
14. - level: Request
15. resources:
16. - group: ""
17. resources: ["configmaps"] #根据题目要求修改，比如题目要求的是 persistentvolumes 或者 pods。
18. namespaces: ["front-apps"]
19. - level: Metadata
20. resources:
21. - group: ""
22. resources: ["secrets", "configmaps"]
23. # Also, add a catch-all rule to log all other requests at the Metadata level.
24. - level: Metadata
25. omitStages:
26. - "RequestReceived"

复制代码

设置 master 节点的 kube-apiserver.yaml

1. root@master01:~$ cp /etc/kubernetes/manifests/kube-apiserver.yaml /bak1
2. root@master01:~$ vi /etc/kubernetes/manifests/kube-apiserver.yaml
3. #定义审计策略 yaml 文件位置，通过 hostpath 挂载
4. - --audit-policy-file=/etc/kubernetes/logpolicy/sample-policy.yaml
5. #定义审计日志位置，通过 hostpath 挂载
6. - --audit-log-path=/var/log/kubernetes/audit-logs.txt
7. #定义保留旧审计日志文件的最大天数为 10 天
8. - --audit-log-maxage=10
9. #定义要保留的审计日志文件的最大数量为 2 个
10. - --audit-log-maxbackup=2
11. root@master01:~$ systemctl daemon-reload
12. root@master01:~$ systemctl restart kubelet
13. root@master01:~$ kubectl get pod -A
14. root@master01:~$ tail /var/log/kubernetes/audit-logs.txt
15. exit,exit

复制代码

6、创建 Secret

Task
在 namespace istio-system 中获取名为 db1-test 的现有 secret 的内容
将 username 字段存储在名为 /cks/sec/user.txt 的文件中，并将 password 字段存储在名为 /cks/sec/pass.txt 的文件中。
留意：你必须创建以上两个文件，他们还不存在。
留意：不要在以下步骤中使用/修改先前创建的文件，如果需要，可以创建新的暂时文件。
在 istio-system namespace 中创建一个名为 db2-test 的新 secret，内容如下：
username : production-instance
password : KvLftKgs4aVH
最后，创建一个新的 Pod，它可以通过卷访问 secret db2-test ：
Pod 名称 secret-pod
Namespace istio-system
容器名 dev-container
镜像 nginx
卷名 secret-volume
挂载路径 /etc/secret
1 将 db1-test 的 username 和 password，通过 base64 解码保存到题目指定文件：

1. candidate@node01:~$ kubectl get secrets db1-test -n istio-system -o yaml
2. candidate@node01:~$ echo 'ZGIx'|base64 -d > /cks/sec/user.txt
3. candidate@node01:~$ echo 'aGVsbG8='|base64 -d > /cks/sec/pass.txt
4. candidate@node01:~$ cat /cks/sec/user.txt
5. candidate@node01:~$ cat /cks/sec/pass.txt

复制代码

2 创建名为 db2-test 的 secret 使用题目要求的用户名和密码作为键值。留意要加命名空间。

1. candidate@node01:~$ kubectl create secret -h
2. candidate@node01:~$ kubectl create secret generic -h
3. candidate@node01:~$ kubectl create secret generic db2-test -n istio-system --from-literal=username=production-instance --from-literal=password=KvLftKgs4aVH
4. candidate@node01:~$ kubectl get secret -n istio-system

复制代码

3 创建 Pod 使用该 secret

1. # 搜secret
2. candidate@node01:~$ vim k8s-secret.yaml
3. apiVersion: v1
4. kind: Pod
5. metadata:
6. name: secret-pod #pod 名字
7. namespace: istio-system #命名空间
8. spec:
9. containers:
10. - name: dev-container #容器名字
11. image: nginx #镜像名字
12. imagePullPolicy: IfNotPresent
13. volumeMounts: #挂载路径
14. - name: secret-volume #卷名
15. mountPath: /etc/secret
16. volumes:
17. - name: secret-volume #卷名
18. secret:
19. secretName: db2-test #名为 db2-test 的 secret
20. candidate@node01:~$ kubectl apply -f k8s-secret.yaml
21. candidate@node01:~$ kubectl get pod -n istio-system

复制代码

7、Dockerfile 检测

Task
分析和编辑给定的 Dockerfile /cks/docker/Dockerfile（基于 ubuntu:16.04 镜像），
并修复在文件中拥有的突出的安全/最佳实践问题的两个指令。
分析和编辑给定的清单文件 /cks/docker/deployment.yaml ，
并修复在文件中拥有突出的安全/最佳实践问题的两个字段。
留意：请勿添加或删除设置设置；只需修改现有的设置设置让以上两个设置设置都不再有安全/最佳实践问题。
留意：如果您需要非特权用户来实行任何项目，请使用用户 ID 65535 的用户 nobody 。
只修改即可，不需要创建。
1 修改 Dockerfile

1. candidate@node01:~$ vi /cks/docker/Dockerfile
2. 1、修改基础镜像为题目要求的 ubuntu:16.04
3. FROM ubuntu:16.04
4. 2、仅将 CMD 上面的 USER root 修改为 USER nobody，不需要改其他的 USER root。
5. USER nobody

复制代码

2 修改 deployment.yaml

1. candidate@node01:~$ vi /cks/docker/deployment.yaml
2. 1、需要将原先的 run: couchdb 修改为 app: couchdb
3. app: couchdb
4. 2、确保 'privileged': 为 False ，确保'readonlyRootFilesystem': 为 True，确保'runAsUser': 为 65535
5. securityContext:
6. {'capabilities': {'add': ['NET_BIND_SERVICE'], 'drop': ['all']}, 'privileged': False, 'readOnlyRootFilesystem': True, 'runAsUser': 65535}

复制代码

8、沙箱运行容器 gVisor

Context
该 cluster 使用 containerd 作为 CRI 运行时。containerd 的默认运行时处理程序是 runc。
containerd 已准备好支持额外的运行时处理程序 runsc (gVisor)。
Task
使用名为 runsc 的现有运行时处理程序，创建一个名为 untrusted 的 RuntimeClass。
更新 namespace server 中的所有 Pod 以在 gVisor 上运行。
您可以在 /cks/gVisor/rc.yaml 中找到一个模版清单。
1 创建 RuntimeClass

1. # 搜 runtimeclass
2. candidate@node01:~$ vi /cks/gVisor/rc.yaml
3. apiVersion: node.k8s.io/v1
4. kind: RuntimeClass
5. metadata:
6. name: untrusted # 用来引用 RuntimeClass 的名字
7. handler: runsc # 对应的 CRI 配置的名称
8. candidate@node01:~$ kubectl create -f /cks/gVisor/rc.yaml
9. candidate@node01:~$ kubectl get RuntimeClass

复制代码

2 将命名空间为 server 下的 Pod 引用 RuntimeClass

1. candidate@node01:~$ kubectl -n server get deployment
2. candidate@node01:~$ kubectl -n server edit deployments busybox-run
3. candidate@node01:~$ kubectl -n server edit deployments nginx-host
4. candidate@node01:~$ kubectl -n server edit deployments run-test
5. spec: #找到这个 spec，注意在 deployment 里是有两个单独行的 spec 的，要找第二个，也就是下面有 containers 这个字段的 spec。
6. runtimeClassName: untrusted #添加这一行，注意空格对齐
7. containers:
8. candidate@node01:~$ kubectl -n server get pod

复制代码

9、网络战略 NetworkPolicy

Task
创建一个名为 pod-restriction 的 NetworkPolicy 来限制对在 namespace dev-team 中运行的 Pod products-service 的访问。
只允许以下 Pod 毗连到 Pod products-service

• namespace qaqa 中的 Pod
  
• 位于任何 namespace，带有标签 environment: testing 的 Pod
  

留意：确保应用 NetworkPolicy。
你可以在/cks/net/po.yaml 找到一个模板清单文件。
1 检查 namespace 标签

1. # 查看 qaqa 命名空间标签（name: qaqa）
2. candidate@node01:~$ kubectl get ns --show-labels
3. # 查看 pod 标签（environment: testing）
4. candidate@node01:~$ kubectl get pod -n dev-team --show-labels
5. # 如果 Pod 或者 Namespace 没有标签，则需要打上标签。
6. candidate@node01:~$ kubectl label ns qaqa name=qaqa
7. candidate@node01:~$ kubectl label pod products-service environment=testing -n dev-team

复制代码

2 创建 NetworkPolicy

1. candidate@node01:~$ vi /cks/net/po.yaml
2. # 查networkpolicy，根据官网，修改为如下内容：
3. ……
4. metadata:
5.   name: pod-restriction #修改
6.   namespace: dev-team #修改
7. spec:
8.   podSelector:
9.     matchLabels:
10.       environment: testing
11.   policyTypes:
12.     - Ingress #注意，这里只写 - Ingress，不要将 - Egress 也复制进来！
13.   ingress:
14.     - from: #第一个 from
15.         - namespaceSelector:
16.             matchLabels:
17.               name: qaqa #命名空间有 name: qaqa 标签的
18.     - from: #第二个 from
19.         - namespaceSelector: {} #修改为这样，所有命名空间
20.           podSelector:  #注意，这个 podSelector 前面的“-” 要删除。
21.             matchLabels:
22.               environment: testing #有 environment: testing 标签的 Pod，这个地方是根据题目要求“Pods with label environment: testing , in any namespace”，这句话里的 pod 标签写的。不要和上面 spec 里的混淆。
23. #创建
24. candidate@node01:~$ kubectl apply -f /cks/net/po.yaml
25. #检查
26. candidate@node01:~$ kubectl describe networkpolicy -n dev-team

复制代码

10、Trivy 扫描镜像安全毛病

Task
使用 Trivy 开源容器扫描器检测 namespace kamino 中 Pod 使用的具有严重毛病的镜像。
查找具有 High 或 Critical 严重性毛病的镜像，并删除使用这些镜像的 Pod。
留意：Trivy 仅安装在 cluster 的 master 节点上，
在工作节点上不可使用。
你必须切换到 cluster 的 master 节点才气使用 Trivy。
1 切换到 Master 的 candidate 下

candidate@node01:~$ ssh master01
2 获取命名空间 kamino 下的所有 pod 和其 image 的对应关系

kubectl get pods --namespace kamino --output=custom-columns="NAME:.metadata.name,IMAGE:.spec.containers

.image"
3 检查镜像是否有高危和严重的毛病

1. candidate@master01:~$ trivy image -h
2. for i in {amazonlinux:1,amazonlinux:2,nginx:1.19,vicuu/nginx:host}; do trivy image -s "HIGH,CRITICAL" $i >> 10.txt;done

复制代码

4 删除有问题的 pod

candidate@master01:~$ kubectl -n kamino delete pod XXXX --force
exit
11、AppArmor

Context
APPArmor 已在 cluster 的工作节点 node02 上被启用。一个 APPArmor 设置文件已存在，但尚未被实施。
Task
在 cluster 的工作节点 node02 上，实施位于 /etc/apparmor.d/nginx_apparmor 的现有 APPArmor 设置文件。 编辑位于 /cks/KSSH00401/nginx-deploy.yaml 的现有清单文件以应用 AppArmor 设置文件。
最后，应用清单文件并创建此中指定的 Pod 。
请留意，考试时，考题里已表明 APPArmor 在工作节点上，所以你需要 ssh 到开头写的工作节点上。
在模拟环境，你需要 ssh 到 node02 这个工作节点。
1 切换到 node02 的 root 下

1. candidate@node01:~$ ssh node02
2. candidate@node02:~$ sudo -i

复制代码

2 切换到 apparmor 的目录

1. root@node02:~$ cd /etc/apparmor.d/
2. root@node02:~$ cat nginx_apparmor

复制代码

3 实行 apparmor 战略模块

1. root@node02:~$ apparmor_status #查不到，没启动
2. root@node02:~$ apparmor_parser /etc/apparmor.d/nginx_apparmor #启用
3. root@node02:~$ apparmor_status# 再次检查有结果了

复制代码

4 修改 pod 文件

留意！留意！考试时，这个文件是在默认登录的终端那个初始节点上的，而不是在这个 work 节点的。
exit exit

1. 搜apparmor
2. candidate@node01:~$ vi /cks/KSSH00401/nginx-deploy.yaml
3. name: podx
4. annotations:
5. container.apparmor.security.beta.kubernetes.io/podx: localhost/nginx-profile-3
6. candidate@node01:~$ kubectl apply -f /cks/KSSH00401/nginx-deploy.yaml
7. candidate@node01:~$ kubectl get pod

复制代码

12、Sysdig & falco

Task：
使用运行时检测工具来检测 Pod redis123 单个容器中频发生成和实行的异常进程。
有两种工具可供使用：

• sysdig
  
• falco
  

注： 这些工具只预装在 cluster 的工作节点 node02 上，不在 master 节点。
使用工具至少分析 30 秒 ，使用过滤器检查生成和实行的进程，将事件写到 /opt/KSR00101/incidents/summary 文件中，
此中包含检测的事件， 格式如下： timestamp,uid/username,processName
保持工具的原始时间戳格式不变。
注： 确保事件文件存储在集群的工作节点上。
请留意，考试时，考题里已表明 sysdig 和 falco 在工作节点上，所以你需要 ssh 到开头写的工作节点上。但在模拟环境，你需要 ssh 到 node02 这个工作节点。
1、切换到 node02 的 root 下

1. candidate@node01:~$ ssh node02
2. candidate@node02:~$ sudo -i

复制代码

2、确认题目里所要求 Pod 的唯一标识，比如 ContainerID。

root@node02:~$ crictl ps | grep redis123
3、编辑 falco 规则 手动输入以下内容，强行背过

1. root@node02:~$ vim /etc/falco/falco_rules.local.yaml
2. - rule: rule1
3. desc: rule1
4. condition: container.name = "redis123"
5. output: "%evt.time,%user.uid,%proc.name"
6. priority: WARNING
7. root@node02:~$ sudo falco -M 30 -r /etc/falco/falco_rules.local.yaml >> /opt/KSR00101/incidents/summary
8. root@node02:~$ vim /etc/falco/falco_rules.local.yaml
9. output: "%evt.time,%user.name,%proc.name"
10. root@node02:~$ sudo falco -M 30 -r /etc/falco/falco_rules.local.yaml >> /opt/KSR00101/incidents/summary

复制代码

4、查看保存的文件

root@node02:~$ cat /opt/KSR00101/incidents/summary
exit exit
13、Container 安全上下文

Context
Container Security Context 应在特定 namespace 中修改 Deployment。
Task
按照如下要求修改 sec-ns 命名空间里的 Deployment secdep
一、用 ID 为 30000 的用户启动容器（设置用户 ID 为: 30000）
二、不允许进程得到超出其父进程的特权（禁止 allowPrivilegeEscalation）
三、以只读方式加载容器的根文件系统（对根文件的只读权限）

1. 搜context 安全上下文
2. candidate@node01:~$ kubectl -n sec-ns edit deployment secdep
3. name: sec-ctx-demo-1 / 2
4. securityContext: #新增或修改 containers 里面第一个 image 的此字段。
5.   allowPrivilegeEscalation: false
6.   readOnlyRootFilesystem: true
8. securityContext: #修改模拟环境里的这一行，注意要删除{}。如果考试时没有搜到，则新增这一行。
9.   runAsUser: 30000
10. candidate@node01:~$ kubectl -n sec-ns get all

复制代码

14、TLS 安全设置

Task
通过 TLS 加强 kube-apiserver 安全设置，要求
1、kube-apiserver 除了 TLS 1.3 及以上的版本可以使用，其他版本都不允许使用。
2、密码套件（Cipher suite）为 TLS_AES_128_GCM_SHA256
通过 TLS 加强 ETCD 安全设置，要求 1、密码套件（Cipher suite）为 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
1 切换到 Master 的 root 下

1. candidate@node01:~$ ssh master01
2. candidate@master01:~$ sudo -i
3. candidate@master01:~$ cp /etc/kubernetes/manifests/kube-apiserver.yaml /tmp

复制代码

2 修改 kube-apiserver

1. #搜kube-api server
2. candidate@master01:~$ vim /etc/kubernetes/manifests/kube-apiserver.yaml
3. - --tls-cipher-suites=TLS_AES_128_GCM_SHA256
4. - --tls-min-version=VersionTLS13 #如果题目要求 TLS 1.2，则就写 VersionTLS12

复制代码

3 等候 apiserver 主动重启，且恢复正常。

candidate@master01:~$ kubectl -n kube-system get pod
4 修改 etcd

1. candidate@master01:~$ cp /etc/kubernetes/manifests/etcd.yaml /tmp
2. candidate@master01:~$ vim /etc/kubernetes/manifests/etcd.yaml
3. - --cipher-suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

复制代码

5 等候 etcd 主动重启，且恢复正常。

1. root@master01:~$ systemctl daemon-reload
2. root@master01:~$ systemctl restart kubelet.service
3. root@master01:~$ kubectl -n kube-system get pod

复制代码

exit exit
15、启用 API server 认证

Context
由 kubeadm 创建的 cluster 的 Kubernetes API 服务器，出于测试目的，
暂时设置允许未经身份验证和未经授权的访问，授予匿名用户 cluster-admin 的访问权限.
Task
重新设置 cluster 的 Kubernetes APl 服务器，以确保只允许经过身份验证和授权的 REST 请求。
使用授权模式 Node,RBAC 和准入控制器 NodeRestriction。
删除用户 system:anonymous 的 ClusterRoleBinding 来进行清理。
留意：所有 kubectl 设置环境/文件也被设置使用未经身份验证和未经授权的访问。
你不必更改它，但请留意，一旦完成 cluster 的安全加固， kubectl 的设置将无法工作。
您可以使用位于 cluster 的 master 节点上，cluster 原本的 kubectl 设置文件
/etc/kubernetes/admin.conf ，以确保经过身份验证的授权的请求仍然被允许。
模拟环境里，初始化这道题的脚本为 api.sh
1、切换集群

1. candidate@node01:~$ ssh master01
2. candidate@master01:~$ sudo -i
3. root@master01:~$ sh api.sh

复制代码

2 确保只有认证并且授权过的 REST 请求才被允许

1. root@master01:~$ mkdir bak15
2. root@master01:~$ cd bak15
3. root@master01:~$ cp /etc/kubernetes/manifests/kube-apiserver.yaml .
4. root@master01:~$ vi /etc/kubernetes/manifests/kube-apiserver.yaml
5. 修改为
6. - --authorization-mode=Node,RBAC
7. - --enable-admission-plugins=NodeRestriction
8. - --anonymous-auth=false

复制代码

3 等候 apiserver 主动重启，且恢复正常。

1. root@master01:~$ systemctl daemon-reload
2. root@master01:~$ systemctl restart kubelet.service
3. root@master01:~$ kubectl get pod -A

复制代码

4 删除题目要求的角色绑定

1. # 查
2. root@master01:~$ kubectl get clusterrolebinding system:anonymous
3. # 删
4. root@master01:~$ kubectl delete clusterrolebinding system:anonymous
5. # 再检查
6. root@master01:~$ kubectl get clusterrolebinding system:anonymous

复制代码

exit exit
16、ImagePolicyWebhook 容器镜像扫描

Context
cluster 上设置了容器镜像扫描器，但尚未完全集成到 cluster 的设置中。
完成后，容器镜像扫描器应扫描并拒绝易受攻击的镜像的使用。
Task
留意：你必须在 cluster 的 master 节点上完成整个考题，所有服务和文件都已被准备好并放置在该节点上。
给定一个目录 /etc/kubernetes/epconfig 中不完整的设置，
以及具有 HTTPS 端点 https://image-bouncer-webhook.default.svc:1323/image_policy 的功能性容器镜像扫描器：

• 启用须要的插件来创建镜像战略
  
• 校验控制设置并将其更改为隐式拒绝（implicit deny）
  
• 编辑设置以正确指向提供的 HTTPS 端点
  

最后，通过尝试部署易受攻击的资源 /cks/img/web1.yaml 来测试设置是否有效。
模拟环境里，初始化这道题的脚本为 imagePolicy.sh
1、切换到 Master 的 root 下

1. candidate@node01:~$ ssh master01
2. candidate@master01:~$ sudo -i
3. root@master01:~$ sh imagePolicy.sh

复制代码

2、编辑 admission_configuration.json 修改 defaultAllow 为 false

1. root@master01:~$ vim /etc/kubernetes/epconfig/admission_configuration.json
2. "defaultAllow": false #将 true 改为 false

复制代码

3、编辑kubeconfig.yml，添加 webhook server 地址：

1. root@master01:~$ vi /etc/kubernetes/epconfig/kubeconfig.yml
2. - cluster: #下面添加
3. server: https://image-bouncer-webhook.default.svc:1323/image_policy #添加 webhook server 地址

复制代码

4、编辑 kube-apiserver.yaml，从官网中引用 ImagePolicyWebhook 的设置信息

1. root@master01:~$ cp /etc/kubernetes/manifests/kube-apiserver.yaml /tmp
2. root@master01:~$ vi /etc/kubernetes/manifests/kube-apiserver.yaml
3. #搜imagepolicywebhook
4. - --enable-admission-plugins=NodeRestriction,ImagePolicyWebhook
5. - --admission-control-config-file=/etc/kubernetes/epconfig/admission_configuration.json

复制代码

5、等候 apiserver 主动重启，且恢复正常。

1. root@master01:~$ systemctl daemon-reload
2. root@master01:~$ systemctl restart kubelet.service
3. root@master01:~$ kubectl -n kube-system get podroot@master01:~$ kubectl apply -f /cks/img/web1.yaml不允许创建

复制代码

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。