The Certified Kubernetes Security Specialist (CKS) (CKS)

Cluster : dev

Master node:  master1

Worker node:  worker1

You can switch the cluster/configuration context using the following command:

[desk@cli] $  kubectl config use-context dev  

Task:

Retrieve the content of the existing secret named  adam  in the  safe  namespace.

Store the username field in a file names  /home/cert-masters/username.txt , and the password field in a file named  /home/cert-masters/password.txt .

1. You must create both files; they don ' t exist yet.

2. Do not use/modify the created files in the following steps, create new temporary files if needed. 

Create a new secret names  newsecret  in the  safe  namespace, with the following content:

Username:  dbadmin

Password:  moresecurepas

Finally, create a new Pod that has access to the secret  newsecret  via a volume:

Namespace: safe

Pod name: mysecret-pod

Container name: db-container

Image: redis

Volume name: secret-vol

Mount path: /etc/ mysecret

You can switch the cluster/configuration context using the following command:

[desk@cli] $  kubectl config use-context dev  

A default-deny NetworkPolicy avoid to accidentally expose a Pod in a namespace that doesn ' t have any other NetworkPolicy defined.

Task:  Create a new default-deny NetworkPolicy named  deny-network  in the namespace  test  for all traffic of type Ingress + Egress

The new NetworkPolicy must deny all Ingress + Egress traffic in the namespace  test .

Apply the newly created  default-deny  NetworkPolicy to all Pods running in namespace  test .

You can find a skeleton manifests file at /home/cert_masters/network-policy.yaml

Secrets stored in the etcd is not secure at rest, you can use the etcdctl command utility to find the secret value

for e.g:-

ETCDCTL_API=3 etcdctl get /registry/secrets/default/cks-secret --cacert= " ca.crt " --cert= " server.crt " --key= " server.key "

Output

Using the Encryption Configuration, Create the manifest, which secures the resource secrets using the provider AES-CBC and identity, to encrypt the secret-data at rest and ensure all secrets are encrypted with the new configuration.

On the Cluster worker node, enforce the prepared AppArmor profile

#include < tunables/ global >

 

profile nginx-deny flags=(attach_disconnected) {

  #include < abstractions/ base >

 

  file,

 

  # Deny all file writes.

  deny /** w,

}

EOF '

Edit the prepared manifest file to include the AppArmor profile.

apiVersion: v1

kind: Pod

metadata:

  name: apparmor-pod

spec:

  containers:

  - name: apparmor-pod

    image: nginx

Finally, apply the manifests files and create the Pod specified on it.

Verify: Try to make a file inside the directory which is restricted.

Two tools are pre-installed on the cluster ' s worker node :

sysdig

falco

Using the tool of your choice (including any non pre-installed tool), analyze the container ' s behavior for at least 30 seconds, using filters that detect newly spawning and executing processes.

Store an incident file at /opt/KSRS00101/alerts/details, containing the detected incidents, one per line, in the following format:

The following example shows a properly formatted incident file:

You must complete this task on the following cluster/nodes: Cluster:  immutable-cluster

Master node:  master1

Worker node:  worker1

You can switch the cluster/configuration context using the following command:

[desk@cli] $   kubectl config use-context immutable-cluster 

Context : It is best practice to design containers to be stateless and immutable.

Task :

Inspect Pods running in namespace  prod  and delete any Pod that is either not stateless or not immutable.

Use the following strict interpretation of stateless and immutable:

1. Pods being able to store data inside containers must be treated as not stateless. 

Note:  You don ' t have to worry whether data is actually stored inside containers or not already.

2. Pods being configured to be  privileged  in any way must be treated as potentially not stateless or not immutable.

You can switch the cluster/configuration context using the following command:

[desk@cli] $  kubectl config use-context prod-account  

Context:

A Role bound to a Pod ' s ServiceAccount grants overly permissive permissions. Complete the following tasks to reduce the set of permissions.

Task:

Given an existing Pod named  web-pod  running in the namespace  database .

1. Edit the existing Role bound to the Pod ' s ServiceAccount  test-sa  to only allow performing get operations, only on resources of type Pods.

2. Create a new Role named  test-role-2  in the namespace  database , which only allows performing  update  operations, only on resources of type  statuefulsets .

3. Create a new RoleBinding named  test-role-2-bind  binding the newly created Role to the Pod ' s ServiceAccount.

Note: Don ' t delete the existing RoleBinding.

You must complete this task on the following cluster/nodes:

Cluster:  trace

Master node:  master

Worker node:  worker1

You can switch the cluster/configuration context using the following command:

[desk@cli] $  kubectl config use-context trace    

Given : You may use Sysdig or Falco documentation. 

Task:

Use detection tools to detect anomalies like processes spawning and executing something weird frequently in the single container belonging to Pod  tomcat . 

Two tools are available to use:

1.    falco

2.   sysdig

Tools are pre-installed on the worker1 node only.

Analyse the container’s behaviour for at least 40 seconds, using filters that detect newly spawning and executing processes. 

Store an incident file at  /home/cert_masters/report , in the following format:

[timestamp],[uid] ,[processName]

Note:   Make sure to store incident file on the cluster ' s worker node, don ' t move it to master node.

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