三天稳过cks终极秘籍

考试心得

最近考过了cks，和大家说说这个备考的过程，以及一些注意事项。

怎样能拿到这个CKS的证呢？相信大家是都可以的，但是有一个好的方法会让我们事倍功半。

首先，以我的经验来说，我总共真实做题的时间三天左右。但这个三天是由包含很多东西，有前提条件的。我觉得你们也可以在三天可以。

对于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.26 考题中这项没给出，但最好也检查一下，模拟环境是里需要改的）
修复针对 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



#注意看清楚题目中给的要求，然后注意配置文件的备份，万一会错误，要注意位置。

2、Pod指定ServiceAccount

Context

您组织的安全策略包括：

⚫ ServiceAccount 不得自动挂载 API 凭据

⚫ ServiceAccount 名称必须以“-sa”结尾

清单文件 /cks/sa/pod1.yaml 中指定的 Pod 由于 ServiceAccount 指定错误而无法调度。

请完成一下项目：

Task

\1. 在现有 namespace qa 中创建一个名为 backend-sa 的新 ServiceAccount，

确保此 ServiceAccount 不自动挂载 API 凭据。

\2. 使用 /cks/sa/pod1.yaml 中的清单文件来创建一个 Pod。

\3. 最后，清理 namespace qa 中任何未使用的 ServiceAccount。

1.创建一个新的sa 的yaml文件。

2.在已有的yaml 修改pod文件

3.先查看sa 在grep ，在删除。

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 找到一个模板清单文件。

#概念，服务，负载均衡和联网，网络策略。

拒绝的出入，命名空间。

#最后检查：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。


#参考，api访问，RBAC鉴权、
1、check role的name 。kubectl describe rolebinding -n db 看清楚。然后进行edit，注意资源，以及权限。
进行检查：kubectl describe role role-1 -n db
2、创建通过命令行方式：kubectl create role role-2 --verb=delete --resource=namespaces -n db
kubectl create rolebinding role-2-binding --role=role-2 --serviceaccount=db:account-web -n db

3\检查：kubectl describe robindings -n db

记住 --verb 是权限，可能考 delete 或者 update 等 --resource 是对象，可能考 namespaces 或者 persistentvolumeclaims 等。

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

#任务，监控日志和调式，集群故障排除，审计。

主要看清楚策略对应，然后仔细，别看错。最后在kubeapiserver里面修改四条策略，在文档的最下面。

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


#任务，管理secrets。(解密)
kubectl get secret -n istio-system db1-test -o jsonpath='{.data.username}' | base64 -d > /cks/sec/user.txt
kubectl get secret -n istio-system db1-test -o jsonpath='{.data.password}' | base64 -d > /cks/sec/pass.txt

kubectl create secrt generic db2-test -n istio-system -from-literal=username=production-instance --from-literal=password=KvLftKgs4aVH


#为pod创建secret，在概念，配置，secret。
spec:
containers:
- name: dev-container #容器名字
image: nginx #镜像名字
volumeMounts: #挂载路径
- name: secret-volume #卷名
mountPath: /etc/secret
volumes:
- name: secret-volume #卷名
secret:
secretName: db2-test #名为 db2-test 的 secret

7、Dockerfile 检测

Task

分析和编辑给定的 Dockerfile /cks/docker/Dockerfile（基于 ubuntu:16.04 镜像），

并修复在文件中拥有的突出的安全/最佳实践问题的两个指令。

分析和编辑给定的清单文件 /cks/docker/deployment.yaml ，

并修复在文件中拥有突出的安全/最佳实践问题的两个字段。

注意：请勿添加或删除配置设置；只需修改现有的配置设置让以上两个配置设置都不再有安全/最佳实践问题。

注意：如果您需要非特权用户来执行任何项目，请使用用户 ID 65535 的用户 nobody 。

只修改即可，不需要创建。

8、沙箱运行容器 gVisor

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



#概念，容器，（运行时，runtimeclass）注意处理程序name
没有namespace

更新的pod时deployment 每一个都要更新，更的时name。

注意位置。

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 找到一个模板清单文件。

注意两个标签，ns ，pod。

出入规则，主要在于任何ns ，podselector。

10、Trivy 扫描镜像安全漏洞

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


#参考，kubectl命令，最后，看image
kubectl get pods -n kamino --output=custom-columns="NAME:.metadata.name,IMAGE:.spec.containers[*].image"


一个一个加入。

for i in {}; do trivy image -s HIGH,CRITICAL $i >> 1.txt ;done
for i in `kubectl describe pod -n kamino | grep -i image: | awk '{print $2}'` ;do trivy image -s HIGH,CRITICAL $i >> 1.txt ;done

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 这个工作节点。

在node02上面启动这个目录文件。回退到原始节点。

#添加 annotations，kubernetes.io/podx 名字要和 containers 里的 name 一样，nginx-profile-3 为前面在 worker node02 上执行的 apparmor 策略模块的名字。

annotations:

container.apparmor.security.beta.kubernetes.io/podx: localhost/nginx-profile-3 #注意要修改。

检测。通过检查该配置文件的 proc attr 来验证容器是否实际使用该配置文件运行：

kubectl exec podx --cat /proc/1/attr/current

12、Sysdig & falco

Task：
使用运行时检测工具来检测 Pod redis123 单个容器中频发生成和执行的异常进程。
有两种工具可供使用：
⚫ sysdig
⚫ falco
注： 这些工具只预装在 cluster 的工作节点 node02 上，不在 master 节点。
使用工具至少分析 30 秒 ，使用过滤器检查生成和执行的进程，将事件写到 /opt/KSR00101/incidents/summary 文件中，
其中包含检测的事件， 格式如下：
timestamp,uid/username,processName



容器唯一的标识

crictl ps | grep redis123

falco # /etc/falco/local
- rule: rule1
  desc: rule1
  condition: container.name = "redis123"
  output: "%evt.time,%user.uid,%proc.name"
  priority: WARNING

- rule: rule1
  desc: rule1
  condition: container.name = "redis123"
  output: "%evt.time,%user.uid,%proc.name"
  priority: WARNING

sudo falco -M 31 -r /etc/falco/falco_rules.local.yaml >>  /opt/KSR00101/incidents/summary

#执行两次。

13、Container 安全上下文

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



#任务，配置pods和容器，为pod或容器配置安全上下文。
注意下面的  在两个容器下都要配置。
securityContext:
allowPrivilegeEscalation: fasle 
readOnlyRootFilesystem: true

#spec：下设置。
 securityContext:
    runAsUser: 30000

14、启用 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


#参考，组件工具，kube-apiserver
--enable-admission-plugin=NodeRestriction

--authorization-mode=Node,RBAC


kubectl get clusterrolebinding system:anonymous
kubectl delete clusterrolebinding system:anonymous

15、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


#参考，组件，kubeapiserver

ssh master01 sudo -i



--tls-min-version=VersionTLS13
--tls-cipher-suites=TLS_AES_128_GCM_SHA256


etcd.yaml
--cipher-suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

kubectl get pod -n kube-system

16、ImagePolicyWebhook 容器镜像扫描

cluster 上设置了容器镜像扫描器，但尚未完全集成到 cluster 的配置中。
完成后，容器镜像扫描器应扫描并拒绝易受攻击的镜像的使用。
Task
注意：你必须在 cluster 的 master 节点上完成整个考题，所有服务和文件都已被准备好并放置在该节点上。
给定一个目录 /etc/kubernetes/epconfig 中不完整的配置，
以及具有 HTTPS 端点 https://image-bouncer-webhook.default.svc:1323/image_policy 的功能性容器镜像扫描器：
1. 启用必要的插件来创建镜像策略
2. 校验控制配置并将其更改为隐式拒绝（implicit deny）
3. 编辑配置以正确指向提供的 HTTPS 端点
最后，通过尝试部署易受攻击的资源 /cks/img/web1.yaml 来测试配置是否有效。
模拟环境里，初始化这道题的脚本为 imagePolicy.sh


json: false

server: https://image-bouncer-webhook.default.svc:1323/image_policy

--admission-control-config-file
--enable-admission-plugin=ImagePolicyWebhook,NodeRestriction