cks考试心得：
第一题：gVsior
我们需要记住一个gVsior的yaml如何写的
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
name: untrusted
handler: runsc
创建完成之后，可以使用kubectl get runtimeclass 来查看我们的这个策略
然后再去编辑指定ns里面的deployment，一般是有三个。指定这个gVsior的时候，我们记得指定这个沙箱的容器
spec:
runtimeClassName: untrusted
containers:
- name: xxxx
如果我们需要去进一步验证的话，我们则需要进入对应的容器内部里面去输入一个指定：dmesg，如果可以找到gVsiro的字样，则代表成功
第二题：Pod 指定 ServiceAccount
需要做的是创建一个serviceaccount，然后不让这个sa自动挂载凭据。
apiVersion: v1
kind: ServiceAccount
metadata:
name: backend-sa
namespace: qa
automountServiceAccountToken: false
创建完成之后，我们需要去查看一下对应的pod里面的yaml，有没有应用这个sa
spec:
serviceAccountName: backend-sa
containers:
- name: xxxx
然后再去查看一下哪一个sa没有使用到，可以使用一个简单的命令去提取
kubectl get pods -n qa --output=custom-columns="Name:.metadata.name,ServiceAccount:.spec.serviceAccountName"
第三题：kube-bench修复不安全的选项（严格根据题意去操作）
我们在做这一道题的时候需要根据题意去修改。一般来说有三个地方需要修改的，
一个是kube-api的这个yaml文件，这个里面的授权策略要修改为Node和RBAC
vim /etc/kubernetes/manifests/kube-apiserver.yaml
- --authorization-mode=Node,RBAC
- --insecure-port=0
然后去修改对应kubelet的配置文件
vim /var/lib/kubelet/config.yaml
anonymous:
enabled: false #匿名认证需要关闭
......
authorization:
mode: Webhook #认证模式为Webhook
修改完成之后记得去重启一下这个kubelet
最后去修改etcd的这个yaml文件
vim /etc/kubernetes/manifests/etcd.yaml
- --client-cert-auth=true #开启证书认证
第四题：默认网络策略
在操作这个题目的时候，我们需要看清楚题目，看看是禁止ingress还是egress（认真审题）
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all
namespace: testing
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
操作完成之后，我们可以去做一个验证。启动一个pod，然后让他去访问外部的IP
kubectl run web --image=httpd -n testing (用这个名称空间的Pod，去访问其他ns的pod，或者其他的pod访问这个)
第五题：Pod安全策略
首先这一道题目需要去api的yaml里面去启用这个psp的策略
- --enable-admission-plugins=NodeRestriction,PodSecurityPolicy ###启用psp策略，如果考试中没有启用的话
然后去编辑这个psp的策略
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: restrict-policy
spec:
privileged: false
seLinux:
rule: RunAsAny
supplementalGroups:
rule: RunAsAny
fsGroup:
rule: RunAsAny
runAsUser:
rule: RunAsAny
volumes:
- '*'
根据题意创建一个clusterrole、serviceaccount、clusterrolerolebinding
kubectl create clusterrole restrict-access-role --verb=use --resource=psp --resource-name=restrict-policy
kubectl create sa psp-denial-sa -n staging
kubectl create clusterrolebinding dany-access-bind --clusterrole=restrict-access-role --serviceaccount=staging:psp-denial-sa -n staging
第6题：RBAC权限
首先我们需要查看一下这个role，看一下是不是有对应的get svc的权限，如果要没有的话，我们需要去编辑这个role
kubectl edit role role-1 -n db
rule:
- apiGroups: [""]
resources: ["services"]
verbs: ["get"]
如果要是有某个单词写错了，是没有办法保存的。
创建role，sa，binding
kubectl create role role-2 --verb=delete --resource=namespaces -n db
kubectl create rolebinding role-2-binding --role=role-2 --serviceaccount=db:service-account-web -n db
第7题：日志审计audit
这一道题，我们可以先去写这个日志的策略，然后再去添加这api的启用
apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
- "RequsetReceived"
rules:
- level: RequestResponse
resources:
- group: "batch"
resources: ["cronjobs"]
- level: Request
resources:
- group: "apps"
resources: ["deployments"]
namespaces: ["testing"]
- level: Metadata
resources:
- group: ""
resources: ["secrets","configmaps"]
- level: Metadata
omitStages:
- "RequsetReceived"
然后去编写api的yaml文件，这里非常容器出错，重点去检查你的这个策略文件
- --audit-policy-file=/etc/kubernetes/logpolicy/sample-policy.yaml
- --audit-log-path=/var/log/kubernetes/audit-k8s.log
- --audit-log-maxage=5 ###文件最大保留天天数
- --audit-log-maxbackup=2 ###允许存在多少个旧文件
如果下面要是没有挂载对应的配置文件，我们则需要去挂载一下
volumeMounts:
- mountPath: /etc/kubernetes/logpolicy/sample-policy.yaml
name: audit-file
- mountPath: /var/log/kubernetes/
name: audit-log
volumes:
- hostPath:
path: /etc/kubernetes/logpolicy/sample-policy.yaml
type: File
name: audit-file
- hostPath:
path: /var/log/kubernetes/
type: Directory
name: audit-log
最后验证的话，需要去查看一下对应的日志文件
tail -f /var/log/kubernetes/audit-k8s.log ###如果看到有日志输出进来，则代表完成
第八题：创建secret
在创建这个secret之前呢，我们需要把题目中所给的两个值提取出来，并输出到指定的文件当中
kubectl get secret db1-test -n istio-system -o jsonpath={.data.username} |base64 -d >./user.txt
kubectl get secret db1-test -n istio-system -o jsonpath={.data.password} |base64 -d >./password.txt
然后再去创建一个新的secret，按照题目的要求
kubectl create secret generic db2-test --from-literal=username=production-instance --from-literal=password=KvLftKgs4aVH -n istio-system
最后再去创建一个Pod，使用这个secret，挂载的路径为/etc/secret
apiVersion: v1
kind: Pod
metadata:
name: secret-pod
namespace: istio-system
spec:
containers:
- name: dev-container
image: nginx
volumeMounts:
- name: secret-volume
mountPath: /etc/secret
volumes:
- name: secret-volume
secret:
secretName: db2-test
第九题：Dockerfile文件检查
这一道题，是两个文件，一个是Dockerfile的规范，有两个地方不满足，一个是FROM ubuntu:latest 这里要修改成指定的16.04的版本。（根据题意）还有一个地方是USER nobody，这个运行程序之前，要使用普通用户
在deployment这里的yaml，我们有两个地方需要注意：一个是需要删除securityContext：SYS_ADMIN的这个字段，一个是需要查看privileged这个的是不是false。就是关闭特权容器的权限
第十题：容器安全，删除特权Pod
我们在操作这一题的时候，首先先确定命名空间是哪里。然后根据命名空间里面的pod的yaml去筛选
kubectl get pods -n production -o yaml |grep -i "privileged"
{"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"name":"pri001","namespace":"production"},"spec":{"containers":[{"image":"vicuu/nginx:host","imagePullPolicy":"IfNotPresent","name":"pri001","securityContext":{"privileged":true}}]}}
privileged: true
这个是返回的结果，通过结果我们可以判断，是pri001启用了这个特权，我们需要删除掉这个Pod
接下来我们再去看一下这个vlouments挂载的
kubectl get pods pri002 -o yaml -n production |grep -i -C 2 "volumes*"
如果这个命令返回的结果都是serviceaccount的这个无需理会，但是要是挂载的四其他的则需要去删除
这个命令需要逐步去执行，然后再去判断这个信息。如果满足题意则直接删除
第十一题：网络策略
这一道题目的网络策略，一定要审题明确，确定在哪一个命名空间干什么事情。这一个网络策略
apiVersion: v1
kind: NetworkPolicy
metadata:
name: pod-restriction
namespace: dev-team
spec:
podSelector:
matchLabels:
environment: testing
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
name: qa
- from:
- namespaceSelector:
podSelector:
matchLabels:
environment: testing
第十二题：ImagePolicyWebhook策略
首选在做这一道题目的时候，我们需要去修改api的yaml文件，让其支持这个策略。然后还需要去查看是否有挂载。
- --enable-admission-plugins=NodeRestriction,ImagePolicyWebhook ###新增webhook策略
- --admission-control-config-file=/etc/kubernetes/image-policy/admission_configuration.yaml
启用了之后，我们接下来了去修改一下对应的文件，先修改对应的策略文件
把defaultallow修改为false
vim admission_configuration.json
"defaultAllow": false ###这里修改为false
vim kubeconfig.yaml
certificate-authority: /etc/kubernetes/epconfig/webhook.pem
server: https://acme.local:8082/image_policy ###这里修改为指定的路径
kubectl apply -f /cks/img/web1.yaml ###等到yaml起来之后，我们去创建这个yaml去测试
tail /var/log/imagepolicy/roadrunner.log ###查看对应的日志去验证
第十三题：trivy镜像漏洞扫描
这一道题是非常浪费时间的，如果我们要是时间不够的话，可以先去操作后面的题目。等回过头来再去操作这个题目
首先我们需要提取到指定命名空间的Pod和image
kubectl get pods -n kamino --output=custom-columns="Name:.metadata.name,Image:.spec.containers[*].image"
Name Image
tri111 amazonlinux:1
tri222 amazonlinux:2,nginx:1.19
tri333 vicuu/nginx:host,amazonlinux:2
提取出来了之后，我们需要根据题意对这一些镜像进行扫描
trivy image -s HIGH,CRITICAL nginx:1.19
如果要是返回的有这个高危信息和这个严重信息的话，我们需要把这个Pod进行删除的操作
第十四题：启用api-Server 认证
首先需要修改的就是api的yaml文件，以便于启用这个认证
- --authorization-mode=Node,RBAC
- --enable-admission-plugins=NodeRestriction
然后再去根据题意删除指定的clusterrolebinding
kubectl get clusterrolebinding |grep system:anonymous ###查看是否存在，然后进行删除
kubectl delete clusterrolebinding system:anonymous ###删除题目中给的指定的策略
第十五题：Apparmor
做这一道题目的时候，我们首先需要这个策略在哪一个节点上面，然后先去应用这个策略
ssh node02
vim /etc/appar.d/nginx_apparmor
#include <tunables/global>
#nginx-profile-3 ###这一行需要注释
profile nginx-profile-3 flags=(attach_disconnected) {
#include <abstractions/base>
file,
# Deny all file writes.
deny /** w,
}
apparmor_status ###查看状态，记得加载完了之后，重新查看一下状态
apparmor_parser nginx_apparmor ###使用这个模块去加载我们的策略
然后去题目中指定的pod文件去应用
我们需要在metadata中去指定注解以便使用这个apparmor的策略
apiVersion: v1
kind: Pod
metadata:
name: podx
namespace: defaultAllow
annotations:
container.apparmor.security.beta.kubernetes.io/podx: localhost/nginx-profile-3 ###这里一定要仔细
创建这个Pod之后，我们可以登录进去进一步的验证
我们需要查看的是，这个apparmor的策略，如果他要是拒绝所有的创建，那我们进去执行一个读写的命令能报错，就是OK的
root@node02:/home/candidate/KSSH00401# kubectl exec -it podx -- sh
/ # touch txt
touch: txt: Permission denied
/ #
/ #
/ # exit
第十六题： sysdig的使用收集日志
这个题目是非常简单的，我们只需要去收集对应的日志信息即可
题目中让我们收集的是指定的格式
[timestamp],[uid],[processName]
我们需要使用docker命令来获取题目中容器的ID
docker ps |grep tomcat
比如是这个：dad476fc19cd
命令：
sysdig -M 30 -p "%evt.time,%user.uid,%proc.name" container.id=dad476fc19cd > /opt/KSR00101/incidents/summary ###输出到指定的位置
文章评论