CKS考试心得-Toy模板网

这篇具有很好参考价值的文章主要介绍了CKS考试心得。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

考前须知：

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.txt

2 在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-pod
    namespace: istio-system
spec:
    containers:
       - image: nginx
          name: dev-container
          volumeMounts:
          -  name: secret-volume
             mountpath: /etc/secret
   volumes:
   - name: secret-volume
     secret:
       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-sa
  namespace: qa
automountServiceAccountToken: false
3、创建sa
k  create -f  sa.yaml
"

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

apiVersion: v1
kind: Pod
metadata:
  name: backend
  namespace: qa
spec:
  serviceAccountName: backend-sa //就加这一行，在链接里有
  containers:
  - image: nginx:1.9
    imagePullPolicy: IfNotPresent
    name: 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.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: denypolicy
  namespace: testing
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress


kubectl 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 db

rules:
 - 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-restriction
     namespace:  dev-team
spec:
     podSelector: 
          matchLabels:
               name: test
     policyTypes:
     - Ingress
     ingress:
     - 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.yaml
   name: audit
   readOnly: true
- mountPath: /var/log/kubernetes/
   name: audit-log
   readOnly: false
- hostPath:
       path: /etc/kubernetes/logpolicy/sample-policy.yaml
       type:  File
    name: audit  
- hostPath:
        path: /var/log/kubernetes/
       type:  DirectoryOrCreate
    name: 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 RuntimeClass


k  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:1


k  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=NodeRestriction

systemctl 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/epconfig
   name: k8s-admiss
   readOnly: true
- hostPath:
        path:  /etc/kubernetes/epconfig
        type: DirectoryOrCreate
   name: k8s-admiss

systemctl restart kubelet

2. 校验控制配置并将其更改为隐式拒绝（implicit deny）

cd  /etc/kubernetes/epconfig
vim admission_configrtion.yaml
修改 allowdefalut = false

3. 编辑配置以正确指向提供的 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: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  volumes:
  - '*'

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 。
文章来源地址https://www.toymoban.com/news/detail-784013.html

ssh master
apparmor_parser -q /etc/apparmor.d/nginx_apparmor


apiVersion: v1
kind: Pod
metadata:
  name: podx 
  annotations: #添加这一部分
     container.apparmor.security.beta.kubernetes.io/podx: localhost/nginx-profile-3 
spec:
  containers:
  - image: busybox
    imagePullPolicy: IfNotPresent
    name: podx       #这个就是containers下的名字，为podx
    command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
    resources: {}
  nodeName: node01
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}


kubectl apply -f /home/candidate/KSSH00401/nginx-deploy.yaml

到了这里，关于CKS考试心得的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！