CKS 2021最新真题--练习题02.docx

CKS 2021最新真题-练习题021 AppArmor2 PodSecurityPolicy3 sysdig & faloc4 镜像安全5 NetworkPolicy6 dockerfile 检测7 pod 操作8 Trivy9 创建secret10 kube-benct11 gVsior12 NetworkPolicy13 kubelet 参数配置14 审计15 clusterrole16 serviceAccount1 AppArmor题目概述ContextAppArmor is enabled on the cluster's worker node. An AppArmor profile is prepared, but not enforced yet.You may use your browser to open one additional tab to access theAppArmor documentation.TaskOn the cluster's worker node, enforce the prepared AppArmor profile located at /etc/apparmor.d/nginx_apparmor .Edit the prepared manifest file located at /cks/4/pod1.yaml to apply the AppArmor profile.Finally, apply the manifest file and create the pod specified in it.解析$ ssh rootvms62.rhce.cc$ vim /etc/apparmor.d/nginx_apparmor# nginx-profile-3$ apparmor_status | grep nginx$ apparmor_parser -q /etc/apparmor.d/nginx_apparmor$ vim /cks/4/pod1.yamlannotations:container.apparmor.security.beta.kubernetes.io/podx: localhost/nginx-profile-3$ kubectl apply -f /cks/4/pod1.yaml2 PodSecurityPolicy题目概述contextA PodsecurityPolicy shall prevent the creati on of privileged Pods in a specific namespace.TaskCreate a new PodSecurityPolicy named prevent-psp-policy, which prevents the creation of privileged Pods.Create a new ClusterRole named restrict-access-role, which uses the newly created PodSecurityPolicy prevent-psp-policy.Create a new serviceAccount named psp-denial-sa in the existing namespace development.Finally, create a new clusterRoleBinding named dany-access-bind, which binds the newly created ClusterRole restrict-access-role to the newly created serviceAccount psp-denial-sa.解析3 sysdig & faloc题目概述You may use your browser to open one additional tab to access sysdig's documentation or Falco's documentation.Task:Use runtime detection tools to detect anomalous processes spawning and executing frequently inthe single container belorging to Pod redis.Two tools are available to use:sysdigfalcoThe tools are pre-installed on the cluster's worker node only; they are notavailable on the basesystem or the master node.Using the tool of your choice (including any non pre-installed tool), analyse the container'sbehaviour for at least 30 seconds, using filters that detect newly spawning and executingprocesses.Store an incident file at /opt/2/report , containing the detected incidents, one per line, in thefollowing format:timestamp,uid, processNameKeep the tool's original timestamp-format as-is.Make sure to store the incident fileon the cluster's worker node.解析$ ssh rootvms62.rhce.cc$ docker ps | grep redis$ sysdig -l | grep time$ sysdig -l | grep uid$ sysdig -l | grep proc$ sysdig -M 30 -p "*%evt.time,%user.uid,%proc.name" container.id=b1dacef30135 >/opt/2/report4 镜像安全题目概述contextA container image scanner is set up on the cluster, but it's not yet fully integrated into the cluster's configuration. When complete, the container image scanner shall scan for and reject the use of vulnerable images.TaskYou have to complete the entire task on the cluster's master node, where all services and files have been prepared and placed.Given an incomplete configuration in directory /etc/kubernetes/aa and a functional containerimage scanner with HTTPS endpoint http:/192.168.26.60:1323/image_policy:1. Enable the necessary plugins to create an image policy2. validate the control configuration and change it to an implicit deny3. Edit the configuration to point t the provided HTTPS endpoint correctly.Finally , test if the configuration is working by trying to deploy the vulnerable resource/cks/1/web1.yamlYou can find the container image scanner's log file at/var/loglimagepolicyiacme.log解析$ ssh rootvms61.rhce.cc$ cd /etc/kubernetes/aa$ vim admission_configuration.jsondefaultAllow: false$ vim kubeconfig.yamlservice: http:/192.168.26.60:1323/image_policy$ vim /etc/kubernetes/manifests/kube-apiserver.yaml- -enable-admission-plugins=NodeRestriction,ImagePolicyWebhook- -admission-control-config-file=/etc/kubernetes/aa/admission_configuration.json.volumeMounts:- mountPath: /etc/kubernetes/aaname: aavolumes:- hostPath:path: /etc/kubernetes/aaname: aa$ systemctl restart kubelet$ kubectl apply -f /cks/1/web1.yaml5 NetworkPolicy题目概述Taskcreate a NetworkPolicy named pod-access torestrict access to Pod products-service running in namespace development.only allow the following Pods to connect to Pod products-service :Pods in the namespace testingPods with label environment: staging, in any namespaceMake sure to apply the NetworkPolicy.You can find a skelet on manifest file at /cks/6/p1.yaml解析$ kubectl get po -n development -show-labels# NAME READY STATUS RESTARTS AGE LABELS# products-service 1/1 Running 8 94d environment=staging$ kubectl get ns -show-labels.# testingActive94d<none>.$ kubectl label ns testing name=testing$ vim /cks/6/p1.yamlapiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata:name: "pod-access"namespace: "development"spec:podSelector:matchLabels:environment: stagingpolicyTypes:- Ingressingress:- from:- namespaceSelector:matchLabels:name: testing- from:- namespaceSelector:matchLabels:podSelector:matchLabels:environment: staging$ kubectl apply -f /cks/6/p1.yaml6 dockerfile 检测题目概述TaskAnalyze and edit the given Dockerfile (based on the ubuntu:16.04 image) /cks/7/Dockerfile fixing two instructions present in the file being prominent security/best-practice issues.Analyze and edit the given manifest file /cks/7/deployment.yaml fixing two fields present in the file being prominent security/best-practice issues.解析$ vim /cks/7/Dockerfile#USER root$ vim /cks/7/deployment.yaml# securityContext:# "Capabilities": 'add':NET_BIND_SERVICE, 'drop: ', 'privileged': TRUE7 pod 操作题目概述contextlt is best-practice to design containers to best teless and immutable.Tasklnspect Pods running in namespace testing and delete any Pod that is either not stateless or not immutable.use the following strict interpretation of stateless and immutable:Pods being able to store data inside containers must be treated as not stateless.You don't have to worry whether data is actually stored inside containers or not already.Pods being configured to be privileged in any way must be treated as potentially not stateless and not immutable.解析$ kubectl get po -n testing$ kubectl get po -n testing frontent -o yaml | egrep "priv.*: true"# privileged: true$ kubectl delete po -n testing frontent -force$ kubectl get po -n testing pod1 -o jsonpath=.spec.volumes | jq8 Trivy题目概述TaskUse the Trivy open-source container scanner to detect images with severe vulnerabilities used by Pods in the namespace yavin.Look for images with High or Critical severity vulnerabilities,and delete the Pods that use those images.Trivy is pre-installed on the cluster's master node only; it is not available on the base system or the worker nodes. You'll have to connect to the cluster's master node to use Trivy.解析$ ssh rootvms61.rhce.cc$ kubectl get po -n yavin$ kubectl get po -n yavin | grep -v "NAME" | awk 'print $1' > podlist.txt$ while read aa;do echo $aa; kubectl get po -n yavin $aa -o yaml | grep " image:" done < podlist.txt$ trivy image -skip-update amazonlinux:1 | egrep -i "High|Critical"9 创建secret题目概述TaskRetrieve the content of the existing secret named db1-test in the istio-system namespace. store the username field in a file named /cks/11/old-username.txt , and the password field in a file named /cks/11/old-pass.txt.You must create both files; they don't exist yet.Do not use/modify the created files in!the following steps, create new temporaryfiles if needed.Create a new secret named test-workflow in the istio-system namespace, with the followingcontent: nally, create a new Pod that has access to the secret test-workflow via a volume: username : thanos password : hahahahaFinally, create a new Pod that has access to the secret test-workflow via a volume:名称 | 内容pod name | dev-podnamespace | stio-systemcontainer name | dev-containerimage | nginx:1.9volume name | dev-volumemount path | /etc/test-secret解析$ kubectl get secrets -n istio-system db1-test -o jsonpath=.data.username |base64 -d > /cks/11/old-username.txt$ kubectl get secrets -n istio-system db1-test -o jsonpath=.data.password |base64 -d > /cks/11/old-pass.txt$ kubectl create secret generic test-workflow -n istio-system -from-literal=username=thanos -from-literal=password=hahahaha$ vim k8s-secret.yamlapiVersion: v1kind: Podmetadata:name: dev-podspec:containers:- name: dev-containerimage: nginx:1.9volumeMounts:- name: dev-volumemountPath: "/etc/test-secret"readOnly: truevolumes:- name: dev-volumesecret:secretName: test-workflow10 kube-benct题目概述contextACIS Benchmark tool was run against the kubeadm-created cluster and found multiple issues that must be addressed immediately.TaskFix all issues via configuration and restart theaffected components to ensure the new settings take effect.Fix all of the following violations that were found against the API server:Ensure that the 1.2.7 -authorization-mode FAIL argument is not set to AlwaysAllowEnsure that the 1.2.8 -authorization-mode FAIL argument includes NodeEnsure that the 1.2.9 -authorization-mode FAIL argument includes RBACEnsure that the 1.2.18 -insecure-bind-address FAIL argument is not setEnsure that the 1.2.19 -insecure-port FAIL argument is set to 0Fix all of the following violations that were found against the kubelet:Ensure that the 4.2.1 anonymous-auth FAIL argument is set to falseEnsure that the 4.2.2 -authorization-mode FAIL argument is not set to AlwaysAllowUse webhook authn/authz where possible.Fix all of the following violations that were found against etcd:Ensure that the 4.2.1 -client-cert-auth FAIL argument is set to true解析$ ssh rootvms65.rhce.cc$ vim /etc/kubernetes/manifests/kube-apiserver.yaml- -authorization-mode=Node,RBAC#- -insecure-bind-address=0.0.0.0- -insecure-port=0$ kube-bench node$ vim /var/lib/kubelet/config.yamlanonymous:enabled: falseauthorization:mode: Webhook$ vim /etc/kubernetes/manifests/etcd.yaml- -client-cert-auth=true$ systemctl daemon-reload$ systemctl restart kubelet11 gVsior题目概述contextThis cluster uses containerd as CRl runtime. Containerd's default runtime handler is runc.Containerd has been prepared to support an additional runtime handler , runsc(gVisor).TaskCreate a RuntimeClass named untrusted using the prepared runtime handler named runsc.Update all Pods in the namespace client to run on gvisor, unless they are already running on anon-default runtime handler.You can find a skeleton manifest file at /cks/13/rc.yaml解析$ vim /cks/13/rc.yamlapiVersion: node.k8s.io/v1beta1kind: RuntimeClassmetadata:name: untrustedhandler: runsc$ kubectl apply -f /cks/13/rc.yaml$ kubectl edit deployments.apps -n client web1spec:runtimeClassName: untrustedcontainers:- image: nginx:1.912 NetworkPolicy题目概述contextA default-deny NetworkPolicy avoids to accidentally expose a Pod in a namespace that doesn't have any other NetworkPolicy defined.TaskCreate a new default-deny NetworkPolicy named denynetwork in the namespace development for all traffic of type Ingress.The new NetworkPolicy must deny all lngress traffic in the namespace development.Apply the newly created default-deny NetworkPolicy to all Pods running in namespace development.You can find a skeleton manifest file at /cks/15/p1.yaml解析$ vim /cks/15/p1.yamlapiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata:name: "denynetwork"namespace: "development"spec:podSelector: policyTypes:- Ingress$ kubectl apply -f /cks/15/p1.yaml13 kubelet 参数配置题目概述contextkubeadm was used to create the cluster used in this task.TaskReconfigure and restart the cluster's Kubernetes APl server to ensure that only authenticated and authorized REST requests are allowed.Make sure that the new configuration applies to any REST request, including local access.Make sure that any configuration changes are permanent and still enforced after restarting the Kubernetes APl server.解析$ ssh rootvms61.rhce.cc$ vim /etc/kubernetes/manifests/kube-apiserver.yaml- -authorization-mode=Node,RBAC- -enable-admission-plugins=NodeRestriction$ systemctl restart kubelet14 审计题目概述TaskEnable audit logs in the cluster.To do so, enable the log backend, and ensurethat: 1. logs are stored at /var/log/kubernetes/audit-logs.txt 2. log files are retained for 5 days 3. at maximum, a number of 10 auditlog files are retainedA basic policy is provided at /etc/kubernetes/logpolicy/sample-policy.yaml. it only specifies what not to log.The base policy is located on thecluster's master node.Edit and extend the basic policy to log: 1. namespaces changes at RequestResponse level 2. the request body of pods changes in the namespace front-apps 3. configMap and secret changes in all namespaces at the Metadata levelAlso, add a catch-all ruie to log all otherrequests at the Metadata level.Don't forget to apply the modifiedpolicy.解析$ vim /etc/kubernetes/logpolicy/sample-policy.yamlapiVersion: audit.k8s.io/v1 # This is required.kind: Policy# Don't generate audit events for all requests in RequestReceived stage.omitStages:- "RequestReceived"rules:- level: RequestResponseresources:- group: ""resources: "namespaces"- level: Requestresources:- group: ""resources: "pods"namespaces: "front-apps"- level: Metadataresources:- group: ""resources: "secrets", "configmaps"- level: MetadataomitStages:- "RequestReceived"$ vim /etc/kubernetes/manifests/kube-apiserver.yaml- -audit-policy-file=/etc/kubernetes/logpolicy/sample-policy.yaml- -audit-log-path=/var/log/kubernetes/audit-logs.txt- -audit-log-maxage=5- -audit-log-maxbackup=10$ systemctl restart kubelet15 clusterrole题目概述contextA Role bound to a Pod's serviceAccount grants overly permissive permissions.Complete the following tasks to reduce the set of permissions.TaskGiven an existing Pod named web-pod running in the namespace monitoring. Edit the existing Role bound to the Pod's serviceAccount sa-dev-1 to only allow performing list operations, only on resources of type Endpoints.create a new Role named role-2 in the namespace monitoring, which only allows performingupdate operations, only on resources of type persistentvolumeclaims.create