考前须知：
1、一共16题，100分66分及格，考试有两次机会
考试准备：
1、护照或或者包含英文名字证件
2、要选择工作日的早上或者晚上考试，千万不要选择周末去考，否则卡到怀疑人生，影响考试结果
3、提前1小时等待考试，关闭VM，webex、teams等服务就花了30分钟。
题目：
第一题： Secret
1 、在namespace istio-system中获取名为db1-test的现有secret的内容，将username字段存储在名为 /cks/sec/user.txt的文件中，并将password字段存储在名为 /cks/sec/pass.txt的文件中。 注意：你必须创建以上两个文件，他们还不存在。 注意：不要在以下步骤中使用/修改先前创建的文件，如果需要，可以创建新的临时文件。
k get secrets db1-test -n istio-system -o jsonpath={.data.username} | base64 -d > /cks/sec/user.txt
k get secrets db1-test -n istio-system -o jsonpath={.data.password} | base64 -d > /cks/sec/pass.txt2 在istio-system namespace中创建一个名为db2-test的新secret，内容如下：
username : production-instance
password : KvLftKgs4aVH
k create secrets generic db2-test -n istio-system --from-literal=username=production-instance
--from-literal=password=KvLftKgs4aVH
3 最后，创建一个新的Pod，它可以通过卷访问secret db2-test ：
Pod 名称 secret-pod
Namespace istio-system
容器名 dev-container
镜像 nginx
卷名 secret-volume
挂载路径 /etc/secret
apiVersion: v1
kind: Pod
metadata:name: secret-podnamespace: istio-system
spec:containers:- image: nginxname: dev-containervolumeMounts:- name: secret-volumemountpath: /etc/secretvolumes:- name: secret-volumesecret:secretName: db2-test第二题：Pod指定特定ServiveAccount
1. 在现有namespace qa中创建一个名为backend-sa的新ServiceAccount，
确保此ServiceAccount不自动挂载API凭据。
1、#获取sa模板
k create sa backend-sa -n qa --dry-run=client -o yaml > sa.yaml
2、编辑sa.yaml 增加不自动挂载api凭据参数
vim sa.yaml
apiVersion: v1
kind: ServiceAccount
metadata:name: backend-sanamespace: qa
automountServiceAccountToken: false
3、创建sa
k create -f sa.yaml
"2. 使用 /cks/sa/pod1.yaml中的清单文件来创建一个Pod。
apiVersion: v1
kind: Pod
metadata:name: backendnamespace: qa
spec:serviceAccountName: backend-sa //就加这一行，在链接里有containers:- image: nginx:1.9imagePullPolicy: IfNotPresentname: backend"
3. 最后，清理namespace ns中任何未使用的ServiceAccount。
k get ns -n qa
k delete sa 名字第三题：Pod安全
检查在 namespace production中运行的Pod，并删除任何非无状态或非不可变的 Pod。
使用以下对无状态和不可变的严格解释：
l 能够在容器内存储数据的 Pod 的容器必须被视为非无状态的。
注意：你不必担心数据是否实际上已经存储在容器中。
l 被配置为任何形式的特权 Pod 必须被视为可能是非无状态和非不可变的。
"1、删除privilege的pod
k get pod -n production k get pod 名字 -n production -o yaml | egrep -i ""priv.*: true""k delete pod 名字 -n production"
第四题：默认网络策略
为所有类型为Ingress+Egress的流量在namespace testing中创建一个名为denypolicy的新默认拒绝NetworkPolicy。
此新的NetworkPolicy必须拒绝namespace testing中的所有的Ingress + Egress流量。
将新创建的默认拒绝NetworkPolicy应用与在namespace testing中运行的所有Pod。
你可以在 /cks/net/p1.yaml找到一个模板清单文件。
edit p1.yamlapiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: denypolicynamespace: testing
spec:podSelector: {}policyTypes:- Ingress- Egresskubectl create -f p1.yaml第五题：RBAC
一个名为web-pod的现有Pod已在 namespace db中运行。
编辑绑定到 Pod 的 ServiceAccount service-account-web的现有Role，仅允许只对 services类型的资源执行 get操作。
kubectl describe rolebindings -n db
kubectl edit role role-1 -n dbrules:- apiGroups: [""]resources: ["services"]verbs: ["get"]在namespace db中创建一个名为role-2 ，并仅允许只对 namespaces类型的资源执行delete操作的新 Role。
k create role role-2 --verb=delete --resource=namespaces -n db 创建一个名为role-2-binding的新 RoleBinding，
将新创建的 Role 绑定到 Pod 的ServiceAccount
k create rolebinding role-2-binding --role=role-2 --serviceaccount=db: service-account-web -n db第六题：NetworkPolicy
只允许以下Pod连接到Pod products-service
1 namespace qa中的Pod
2 位于任何namespace，带有标签environment: testing的Pod
注意：确保应用NetworkPolicy。
你可以在/cks/net/po.yaml找到一个模板清单文件
vim po.yaml
apiVersion: networking.k8s.io/v1
kind: NetwokPolicy
metadata:name: pod-restrictionnamespace: dev-team
spec:podSelector: matchLabels:name: testpolicyTypes:- Ingressingress:- from:- namespaceSelector:matchlabels:name: qa- from:- namespaceSelector: {}- podSelector:matchLabels:environment: testing第七题： Audit日志审计
在cluster中启用审计日志。为此，请启用日志后端，并确保：
l 日志存储在 /var/log/kubernetes/audit-logs.txt
l 日志文件能保留 10 天
l 最多保留 2 个旧审计日志文件
/etc/kubernetes/logpolicy/sample-policy.yaml
提供了基本策略。它仅指定不记录的内容
ssh master
vim /etc/kubernetes/mainfast/kube-apiserver.conf
--audit-policy-path=/etc/kubernetes/logpolicy/sample-policy.yaml
--audit-log-path=/var/log/kubernetes/audit-logs.txt
--audit-log-maxage=10
--audit-log-maxbackup=2- mountPath: /etc/kubernetes/logpolicy/sample-policy.yamlname: auditreadOnly: true
- mountPath: /var/log/kubernetes/name: audit-logreadOnly: false
- hostPath:path: /etc/kubernetes/logpolicy/sample-policy.yamltype: Filename: audit
- hostPath:path: /var/log/kubernetes/type: DirectoryOrCreatename: audit-log sytemctl restart kubelet注意：基本策略位于cluster的master节点上。
编辑和扩展基本策略以记录：
l RequestResponse 级别的 cronjobs更改
l namespace front-apps中 deployment更改的请求体
l Metadata 级别的所有 namespace 中的 ConfigMap 和 Secret 的更改
此外，添加一个全方位的规则以在 Metadata 级别记录所有其他请求。
#注意 这里是resources的[]里资源对象要加s
apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:- "RequestReceived"
rules:- level: RequestResponse resources:- group: ""resources: ["cronjobs"]- level: Request resources:- group: ""resources: ["deployments"]namespaces: ["front-apps"]- level: Metadata resources:- group: ""resources: ["configmaps","secrets"]- level: Metadata omitStages:- "RequestReceived"k apply -f yaml第七题： Dockerfile检测
#dockerfile
修改两处 #user root 改为 user nobody
修改 image: ubuntu:latest 为 ubuntu:19.2
#deployment.yaml
第一种答案：
注释security context这行
第二种答案：
把securityContext:这里的privileged改为false，然后用户改为runAsUser: 65535第八题： Gvisor
该 cluster使用 containerd作为CRI运行时。containerd的默认运行时处理程序是runc。
containerd已准备好支持额外的运行时处理程序runsc (gVisor)。
使用名为runsc的现有运行时处理程序，创建一个名为untrusted 的RuntimeClass。
更新 namespace server中的所有Pod以在gVisor上运行。
#编写yaml
apiVersion: node.k8s.io/v1beta1
kind: RuntimeClass
metadata:name: untrusted
handler: runsc
#创建
k create -f yaml
#查询
kubectl get RuntimeClassk eidt deployment web1 -n client
在 spec下面添加 runtimeClassName: untrusted第九题：Trivy扫描镜像安全漏洞
使用Trivy开源容器扫描器检测namespace kamino中 Pod 使用的具有严重漏洞的镜像。
查找具有High或Critical严重性漏洞的镜像，并删除使用这些镜像的Pod。
ssh master
k get pod -n kamino --output=custom-columns="Name:.metadata.name,IMAGE: .spec.containers[*].image"
trivy image -s HIGH,CRITICAL amonzline:1k delete pod xxxxx -n kamino --force第十题： Sisdig
使用运行时检测工具来检测 Pod tomcat 单个容器中频发生成和执行的异常进程
有两种工具可供使用：
l sysdig
l falco
注： 这些工具只预装在cluster的工作节点，不在 master 节点。
使用工具至少分析30秒 ，使用过滤器检查生成和执行的进程，将事件写到 /opt/KSR00101/incidents/summary文件中，
其中包含检测的事件， 格式如下：
[timestamp],[uid],[processName]
保持工具的原始时间戳格式不变。
注： 确保事件文件存储在集群的工作节点上
docker ps | grep tomcat
找到containerid
sysdig -M 30 -P "%evt.time,%user.uid,%proc.name" container.id=ID号 > 指定的log名字第十一题： 启用 API server认证
重新配置cluster的Kubernetes APl 服务器，以确保只允许经过身份验证和授权的 REST请求。
使用授权模式 Node,RBAC 和准入控制器 NodeRestriction。
#备份
ssh master
cp /etc/kubernets/mainfast/kube-apiserver.yaml ~/
vim /etc/kubernets/mainfast/kube-apiserver.yaml
- --authorization-mode=Node,RBAC
- --enable-admission-plugins=NodeRestrictionsystemctl resatrt kubelet删除用户 system:anonymous 的 ClusterRoleBinding来进行清理。
注意：所有kubectl 配置环境/文件也被配置使用未经身份验证和未经授权的访问。
你不必更改它，但请注意，一旦完成 cluster 的安全加固， kubectl 的配置将无法工作。
您可以使用位于 cluster 的 master 节点上，cluster 原本的 kubectl 配置文件
/etc/kubernetes/admin.conf ，以确保经过身份验证的授权的请求仍然被允许。
k delete clusterrolebinding system:anonymous第十二题： kube-bench修复
kube-bench 是一个 CIS 评估工具，扫描 kubernetes 集群存在的安全问题，
基本上按照 扫描结果的修复建议进行修复就可以了，系统会给出很具体的修复措施。
# 修复 kube-apiserver 安全问题
#修改：--authorization-mode=Node,RBAC
#添加--insecure-port=0
#删除# --insecure-bind-address=0.0.0.0#修复 kubelet 安全问题
vi /var/lib/kubelet/config.yaml
# 将authentication.anonymous.enabled 设置为 false
authentication:anonymous:enabled: false
# authorization.mode 设置为 Webhook
authorization:mode: Webhook# 修复 etcd 安全问题
vi /etc/kubernetes/manifests/etcd.yaml
# 修改为true：
- --client-cert-auth=true
# 以上修复完成后 重新加载配置文件并重启kubelet
systemctl daemon-reload
systemctl restart kubelet第十三题： ImagePolicyWebhook容器镜像扫描
给定一个目录 /etc/kubernetes/epconfig中不完整的配置以及具有 HTTPS 端点
https://acme.local:8082/image_policy 的功能性容器镜像扫描器：
1. 启用必要的插件来创建镜像策略
最后，通过尝试部署易受攻击的资源 /cks/img/web1.yaml来测试配置是否有效。
你可以在 /var/log/imagepolicy/roadrunner.log 找到容器镜像扫描仪的日志文件。
ssh master
vim /etc/kubernetes/mainfast/kube-apiserver.yaml
- -- enable-admission-plugins=NodeRestriction,ImagePolicyWebhook
- --admission-contorl-config-file=/etc/kubernetes/epconfig/admission_configrtion.yaml
- mountPath: /etc/kubernetes/epconfigname: k8s-admissreadOnly: true
- hostPath:path: /etc/kubernetes/epconfigtype: DirectoryOrCreatename: k8s-admisssystemctl restart kubelet
2. 校验控制配置并将其更改为隐式拒绝（implicit deny）
cd /etc/kubernetes/epconfig
vim admission_configrtion.yaml
修改 allowdefalut = false3. 编辑配置以正确指向提供的 HTTPS 端点
cd /etc/kubernetes/epconfig
vim kubeconfig.yaml
在cluster下面增加：
server: https://acme.local:8082/image_policy 第十四题： PSP
创建一个名为restrict-policy的新的PodSecurityPolicy，以防止特权Pod的创建。
最后，创建一个名为dany-access-bind的ClusterRoleBinding ，
你可以在一下位置找到模版清单文件：
/cks/psp/psp.yaml
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:name: restrict-policy #改下名字
spec:privileged: false # 修改为false seLinux: rule: RunAsAnysupplementalGroups:rule: RunAsAnyrunAsUser:rule: RunAsAnyfsGroup:rule: RunAsAnyvolumes:- '*'k create -f psp.yaml
在现有的namespace staging中创建一个名为psp-denial-sa的新ServiceAccount。
kubectl create sa psp-denial-sa -n staging
创建一个名为restrict-access-role并使用新创建的PodSecurityPolicy restrict-policy的ClusterRole。
kubectl create clusterrole restrict-access-role --verb=use --resource=psp --resource-name=restrict-policy将新创建的ClusterRole restrict-access-role绑定到新创建的ServiceAccount psp-denial-sa。
kubectl create clusterrolebinding dany-access-bind --clusterrole=restrict-access-role --serviceaccount=staging:psp-denial-sa第十五题：AppArmor
在 cluster 的工作节点上，实施位于 /etc/apparmor.d/nginx_apparmor的现有APPArmor 配置文件。
编辑位于 /home/candidate/KSSH00401/nginx-deploy.yaml的现有清单文件以应用 AppArmor 配置文件。
最后，应用清单文件并创建其中指定的 Pod 。
ssh master
apparmor_parser -q /etc/apparmor.d/nginx_apparmorapiVersion: v1
kind: Pod
metadata:name: podx annotations: #添加这一部分container.apparmor.security.beta.kubernetes.io/podx: localhost/nginx-profile-3
spec:containers:- image: busyboximagePullPolicy: IfNotPresentname: podx #这个就是containers下的名字，为podxcommand: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]resources: {}nodeName: node01dnsPolicy: ClusterFirstrestartPolicy: Always
status: {}kubectl apply -f /home/candidate/KSSH00401/nginx-deploy.yaml
