Free Certified Kubernetes Security Specialist Exam CKS Exam Practice Test

You can switch the cluster/configuration context using the following command: [desk@cli] $kubectl config use-context qaContext: A pod fails to run because of an incorrectly specified ServiceAccountTask: Create a new service account named backend-qa in an existing namespace qa, which must not have access to any secret. Edit the frontend pod yaml to use backend-qa service accountNote:You can find the frontend pod yaml at /home/cert_masters/frontend-pod.yaml

• A . Explanation:
  [desk@cli] $k create sa backend-qa -n qa
  sa/backend-qa created
  
  [desk@cli] $k get role,rolebinding -n qa
  No resources found in qa namespace.
  
  [desk@cli] $k create role backend -n qa --resource pods,namespaces,configmaps --verb list
  #No access to secret
  
  [desk@cli] $k create rolebinding backend -n qa --role backend --serviceaccount qa:backend-qa
  
  [desk@cli] $vim /home/cert_masters/frontend-pod.yaml
  apiVersion: v1
  kind: Pod
  metadata:
  name: frontend
  spec:
  serviceAccountName: backend-qa # Add this
  image: nginx
  name: frontend
  [desk@cli] $k apply -f /home/cert_masters/frontend-pod.yaml
  pod created
  [desk@cli] $k create sa backend-qa -n qa
  serviceaccount/backend-qa created
  
  [desk@cli] $k get role,rolebinding -n qa
  No resources found in qa namespace.
  
  [desk@cli] $k create role backend -n qa --resource pods,namespaces,configmaps --verb list
  role.rbac.authorization.k8s.io/backend created
  
  [desk@cli] $k create rolebinding backend -n qa --role backend --serviceaccount qa:backend-qa
  rolebinding.rbac.authorization.k8s.io/backend created
  
  [desk@cli] $vim /home/cert_masters/frontend-pod.yaml
  apiVersion: v1
  kind: Pod
  metadata:
  name: frontend
  spec:
  serviceAccountName: backend-qa # Add this
  image: nginx
  name: frontend
  [desk@cli] $k apply -f /home/cert_masters/frontend-pod.yaml
  pod/frontend created
  
  https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/
  

Create a new ServiceAccount named backend-sa in the existing namespace default, which has the capability to list the pods inside the namespace default.Create a new Pod named backend-pod in the namespace default, mount the newly created sa backend-sa to the pod, and Verify that the pod is able to list pods.Ensure that the Pod is running.

• A . Explanation:
  A service account provides an identity for processes that run in a Pod.
  When you (a human) access the cluster (for example, usingkubectl), you are authenticated by the apiserver as a particular User Account (currently this is usuallyadmin, unless your cluster administrator has customized your cluster). Processes in containers inside pods can also contact the apiserver. When they do, they are authenticated as a particular Service Account (for example,default).
  When you create a pod, if you do not specify a service account, it is automatically assigned thedefaultservice account in the same namespace. If you get the raw json or yaml for a pod you have created (for example,kubectl get pods/ -o yaml), you can see thespec.serviceAccountNamefield has beenautomatically set.
  You can access the API from inside a pod using automatically mounted service account credentials, as described inAccessing the Cluster. The API permissions of the service account depend on theauthorization plugin and policyin use.
  In version 1.6+, you can opt out of automounting API credentials for a service account by settingautomountServiceAccountToken: falseon the service account:
  apiVersion: v1
  kind: ServiceAccount
  metadata:
  name: build-robot
  automountServiceAccountToken: false
  ...
  In version 1.6+, you can also opt out of automounting API credentials for a particular pod:
  apiVersion: v1
  kind: Pod
  metadata:
  name: my-pod
  spec:
  serviceAccountName: build-robot
  automountServiceAccountToken: false
  ...
  The pod spec takes precedence over the service account if both specify aautomountServiceAccountTokenvalue.
  

Analyze and edit the given DockerfileFROM ubuntu:latestRUN apt-get update -yRUN apt-install nginx -yCOPY entrypoint.sh /ENTRYPOINT ['/entrypoint.sh']USER ROOTFixing two instructions present in the file being prominent security best practice issuesAnalyze and edit the deployment manifest fileapiVersion: v1kind: Podmetadata:name: security-context-demo-2spec:securityContext:runAsUser: 1000containers:- name: sec-ctx-demo-2image: gcr.io/google-samples/node-hello:1.0securityContext:runAsUser: 0privileged: TrueallowPrivilegeEscalation: falseFixing two fields present in the file being prominent security best practice issuesDon't add or remove configuration settings; only modify the existing configuration settingsWhenever you need an unprivileged user for any of the tasks, use user test-user with the user id 5487

• A . Explanation:
  FROM debian:latest
  MAINTAINER k@bogotobogo.com
  # 1 - RUN
  RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -yq apt-utils
  RUN DEBIAN_FRONTEND=noninteractive apt-get install -yq htop
  RUN apt-get clean
  # 2 - CMD
  #CMD ['htop']
  #CMD ['ls', '-l']
  # 3 - WORKDIR and ENV
  WORKDIR /root
  ENV DZ version1
  $ docker image build -t bogodevops/demo .
  Sending build context to Docker daemon 3.072kB
  Step 1/7 : FROM debian:latest
  ---> be2868bebaba
  Step 2/7 : MAINTAINER k@bogotobogo.com
  ---> Using cache
  ---> e2eef476b3fd
  Step 3/7 : RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -yq apt-utils
  ---> Using cache
  ---> 32fd044c1356
  Step 4/7 : RUN DEBIAN_FRONTEND=noninteractive apt-get install -yq htop
  ---> Using cache
  ---> 0a5b514a209e
  Step 5/7 : RUN apt-get clean
  ---> Using cache
  ---> 5d1578a47c17
  Step 6/7 : WORKDIR /root
  ---> Using cache
  ---> 6b1c70e87675
  Step 7/7 : ENV DZ version1
  ---> Using cache
  ---> cd195168c5c7
  Successfully built cd195168c5c7
  Successfully tagged bogodevops/demo:latest
  

a. Retrieve the content of the existing secret nameddefault-token-xxxxxin the testing namespace.Store the value of the token in the token.txtb. Create a new secret named test-db-secret in the DB namespace with the following content:username:mysqlpassword:password@123Create the Pod name test-db-pod of image nginx in the namespace db that can access test-db-secret via a volume at path /etc/mysql-credentials

• A . Explanation:
  To add a Kubernetes cluster to your project, group, or instance:
  Navigate to your:
  Project'sOperations > Kubernetespage, for a project-level cluster.
  Group'sKubernetespage, for a group-level cluster.
  Admin Area >Kubernetespage, for an instance-level cluster.
  ClickAdd Kubernetes cluster.
  Click theAdd existing clustertab and fill in the details:
  Kubernetes cluster name(required) - The name you wish to give the cluster.
  Environment scope(required) - Theassociated environmentto this cluster.
  API URL(required) - It's the URL that GitLab uses to access the Kubernetes API. Kubernetes exposes several APIs, we want the ''base'' URL that is common to all of them. For example,https://kubernetes.example.comrather thanhttps://kubernetes.example.com/api/v1.
  Get the API URL by running this command:
  kubectl cluster-info | grep -E 'Kubernetes master|Kubernetes control plane' | awk '/http/ {print $NF}'
  CA certificate(required) - A valid Kubernetes certificate is needed to authenticate to the cluster. We use the certificate created by default.
  List the secrets withkubectl get secrets, and one should be named similar todefault-token-xxxxx. Copy that token name for use below.
  Get the certificate by running this command:
  kubectl get secret <secret name> -o jsonpath='{['data']['ca\.crt']}'
  

Create a RuntimeClass named gvisor-rc using the prepared runtime handler named runsc.Create a Pods of image Nginx in the Namespace server to run on the gVisor runtime class

• A . Explanation:
  Install the Runtime Class for gVisor
  { # Step 1: Install a RuntimeClass
  cat <<EOF | kubectl apply -f -
  apiVersion: node.k8s.io/v1beta1
  kind: RuntimeClass
  metadata:
  name: gvisor
  handler: runsc
  EOF
  }
  Create a Pod with the gVisor Runtime Class
  { # Step 2: Create a pod
  cat <<EOF | kubectl apply -f -
  apiVersion: v1
  kind: Pod
  metadata:
  name: nginx-gvisor
  spec:
  runtimeClassName: gvisor
  containers:
  - name: nginx
  image: nginx
  EOF
  }
  Verify that the Pod is running
  { # Step 3: Get the pod
  kubectl get pod nginx-gvisor -o wide
  }
  

You can switch the cluster/configuration context using the following command: [desk@cli] $kubectl config use-context test-accountTask:Enable audit logs in the cluster.To do so, enable the log backend, and ensure that:1. logs are stored at/var/log/Kubernetes/logs.txt2. log files are retained for5days3. at maximum, a number of10old audit log files are retainedA basic policy is provided at/etc/Kubernetes/logpolicy/audit-policy.yaml. It only specifies what not to log.Note: The base policy is located on the cluster's master node.Edit and extend the basic policy to log: 1.Nodeschanges atRequestResponselevel 2. The request body ofpersistentvolumeschanges in the namespacefrontend 3.ConfigMapandSecretchanges in all namespaces at theMetadatalevelAlso, add a catch-all rule to log all other requests at theMetadatalevelNote:Don't forget to apply the modified policy.

• A . Explanation:
  $vim /etc/kubernetes/log-policy/audit-policy.yaml
  - level: RequestResponse
  userGroups: ['system:nodes']
  - level: Request
  resources:
  - group: '' # core API group
  resources: ['persistentvolumes']
  namespaces: ['frontend']
  - level: Metadata
  resources:
  - group: ''
  resources: ['configmaps', 'secrets']
  - level: Metadata
  $vim /etc/kubernetes/manifests/kube-apiserver.yaml
  Add these
  - --audit-policy-file=/etc/kubernetes/log-policy/audit-policy.yaml
  - --audit-log-path=/var/log/kubernetes/logs.txt
  - --audit-log-maxage=5
  - --audit-log-maxbackup=10
  Explanation
  [desk@cli] $ssh master1
  [master1@cli] $vim /etc/kubernetes/log-policy/audit-policy.yaml
  apiVersion: audit.k8s.io/v1 # This is required.
  kind: Policy
  # Don't generate audit events for all requests in RequestReceived stage.
  omitStages:
  - 'RequestReceived'
  rules:
  # Don't log watch requests by the 'system:kube-proxy' on endpoints or services
  - level: None
  users: ['system:kube-proxy']
  verbs: ['watch']
  resources:
  - group: '' # core API group
  resources: ['endpoints', 'services']
  # Don't log authenticated requests to certain non-resource URL paths.
  - level: None
  userGroups: ['system:authenticated']
  nonResourceURLs:
  - '/api*' # Wildcard matching.
  - '/version'
  # Add your changes below
  - level: RequestResponse
  userGroups: ['system:nodes'] # Block for nodes
  - level: Request
  resources:
  - group: '' # core API group
  resources: ['persistentvolumes'] # Block for persistentvolumes
  namespaces: ['frontend'] # Block for persistentvolumes of frontend ns
  - level: Metadata
  resources:
  - group: '' # core API group
  resources: ['configmaps', 'secrets'] # Block for configmaps & secrets
  - level: Metadata # Block for everything else
  [master1@cli] $vim /etc/kubernetes/manifests/kube-apiserver.yaml
  apiVersion: v1
  kind: Pod
  metadata:
  annotations:
  kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: 10.0.0.5:6443
  labels:
  component: kube-apiserver
  tier: control-plane
  name: kube-apiserver
  namespace: kube-system
  spec:
  containers:
  - command:
  - kube-apiserver
  - --advertise-address=10.0.0.5
  - --allow-privileged=true
  - --authorization-mode=Node,RBAC
  - --audit-policy-file=/etc/kubernetes/log-policy/audit-policy.yaml #Add this
  - --audit-log-path=/var/log/kubernetes/logs.txt #Add this
  - --audit-log-maxage=5 #Add this
  - --audit-log-maxbackup=10 #Add this
  ...
  output truncated
  Note: log volume & policy volume is already mounted invim /etc/kubernetes/manifests/kube-apiserver.yamlso no need to mount it.
  
  Reference:https://kubernetes.io/docs/tasks/debug-application-cluster/audit/
  

Enable audit logs in the cluster, To Do so, enable the log backend, and ensure that1. logs are stored at /var/log/kubernetes-logs.txt.2. Log files are retained for 12 days.3. at maximum, a number of 8 old audit logs files are retained.4. set the maximum size before getting rotated to 200MBEdit and extend the basic policy to log:1. namespaces changes at RequestResponse2. Log the request body of secrets changes in the namespace kube-system.3. Log all other resources in core and extensions at the Request level.4. Log 'pods/portforward', 'services/proxy' at Metadata level.5. Omit the Stage RequestReceivedAll other requests at the Metadata level

• A . Explanation:
  Kubernetes auditing provides a security-relevant chronological set of records about a cluster. Kube-apiserver performs auditing. Each request on each stage of its execution generates an event, which is then pre-processed according to a certain policy and written to a backend. The policy determines what's recorded and the backends persist the records.
  You might want to configure the audit log as part of compliance with the CIS (Center for Internet Security) Kubernetes Benchmark controls.
  The audit log can be enabled by default using the following configuration incluster.yml:
  services:
  kube-api:
  audit_log:
  enabled: true
  When the audit log is enabled, you should be able to see the default values at/etc/kubernetes/audit-policy.yaml
  The log backend writes audit events to a file inJSONlinesformat. You can configure the log audit backend using the followingkube-apiserverflags:
  --audit-log-pathspecifies the log file path that log backend uses to write audit events. Not specifying this flag disables log backend.-means standard out
  --audit-log-maxagedefined the maximum number of days to retain old audit log files
  --audit-log-maxbackupdefines the maximum number of audit log files to retain
  --audit-log-maxsizedefines the maximum size in megabytes of the audit log file before it gets rotated
  If your cluster's control plane runs the kube-apiserver as a Pod, remember to mount thehostPathto the location of the policy file and log file, so that audit records are persisted. For example:
  --audit-policy-file=/etc/kubernetes/audit-policy.yaml \
  --audit-log-path=/var/log/audit.log
  

Service is running on port 389 inside the system, find the process-id of the process, and stores the names of all the open-files inside the /candidate/KH77539/files.txt, and also delete the binary.

• A . Explanation:
  root# netstat -ltnup
  Active Internet connections (only servers)
  Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
  tcp 0 0 127.0.0.1:17600 0.0.0.0:* LISTEN 1293/dropbox
  tcp 0 0 127.0.0.1:17603 0.0.0.0:* LISTEN 1293/dropbox
  tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 575/sshd
  tcp 0 0 127.0.0.1:9393 0.0.0.0:* LISTEN 900/perl
  tcp 0 0 :::80 :::* LISTEN 9583/docker-proxy
  tcp 0 0 :::443 :::* LISTEN 9571/docker-proxy
  udp 0 0 0.0.0.0:68 0.0.0.0:* 8822/dhcpcd
  ...
  root# netstat -ltnup | grep ':22'
  tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 575/sshd
  Thesscommand is the replacement of thenetstatcommand.
  Now let's see how to use thesscommand to see which process is listening on port 22:
  root# ss -ltnup 'sport = :22'
  Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
  tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:('sshd',pid=575,fd=3))
  

Create a PSP that will only allow the persistentvolumeclaim as the volume type in the namespace restricted.Create a new PodSecurityPolicy named prevent-volume-policy which prevents the pods which is having different volumes mount apart from persistentvolumeclaim.Create a new ServiceAccount named psp-sa in the namespace restricted.Create a new ClusterRole named psp-role, which uses the newly created Pod Security Policy prevent-volume-policyCreate a new ClusterRoleBinding named psp-role-binding, which binds the created ClusterRole psp-role to the created SA psp-sa.Hint:Also, Check the Configuration is working or not by trying to Mount a Secret in the pod maifest, it should get failed.POD Manifest:apiVersion: v1kind: Podmetadata:name:spec:containers:- name:image:volumeMounts:- name:mountPath:volumes:- name:secret:secretName:

• A . Explanation:
  apiVersion: policy/v1beta1
  kind: PodSecurityPolicy
  metadata:
  name: restricted
  annotations:
  seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default,runtime/default'
  apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default'
  seccomp.security.alpha.kubernetes.io/defaultProfileName: 'runtime/default'
  apparmor.security.beta.kubernetes.io/defaultProfileName: 'runtime/default'
  spec:
  privileged: false
  # Required to prevent escalations to root.
  allowPrivilegeEscalation: false
  # This is redundant with non-root + disallow privilege escalation,
  # but we can provide it for defense in depth.
  requiredDropCapabilities:
  - ALL
  # Allow core volume types.
  volumes:
  - 'configMap'
  - 'emptyDir'
  - 'projected'
  - 'secret'
  - 'downwardAPI'
  # Assume that persistentVolumes set up by the cluster admin are safe to use.
  - 'persistentVolumeClaim'
  hostNetwork: false
  hostIPC: false
  hostPID: false
  runAsUser:
  # Require the container to run without root privileges.
  rule: 'MustRunAsNonRoot'
  seLinux:
  # This policy assumes the nodes are using AppArmor rather than SELinux.
  rule: 'RunAsAny'
  supplementalGroups:
  rule: 'MustRunAs'
  ranges:
  # Forbid adding the root group.
  - min: 1
  max: 65535
  fsGroup:
  rule: 'MustRunAs'
  ranges:
  # Forbid adding the root group.
  - min: 1
  max: 65535
  readOnlyRootFilesystem: false
  

Create a new NetworkPolicy named deny-all in the namespace testing which denies all traffic of type ingress and egress traffic

• A . Explanation:
  You can create a 'default' isolation policy for a namespace by creating a NetworkPolicy that selects all pods but does not allow any ingress traffic to those pods.
  ---
  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
  name: default-deny-ingress
  spec:
  podSelector: {}
  policyTypes:
  - Ingress
  You can create a 'default' egress isolation policy for a namespace by creating a NetworkPolicy that selects all pods but does not allow any egress traffic from those pods.
  ---
  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
  name: allow-all-egress
  spec:
  podSelector: {}
  egress:
  - {}
  policyTypes:
  - Egress
  Default deny all ingress and all egress traffic
  You can create a 'default' policy for a namespace which prevents all ingress AND egress traffic by creating the following NetworkPolicy in that namespace.
  ---
  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
  name: default-deny-all
  spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  This ensures that even pods that aren't selected by any other NetworkPolicy will not be allowed ingress or egress traffic.