Linux Foundation CKS Quiz 13 Topic 1 Questions 61-65

Question: 1

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.

AExplanation:
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.

Show Answer

Question: 2

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

AExplanation:
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
}

Show Answer

Question: 3

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

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

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

2. log files are retained for5days

3. at maximum, a number of10old audit log files are retained

A 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 theMetadatalevel

Also, add a catch-all rule to log all other requests at theMetadatalevel

Note:Don't forget to apply the modified policy.

AExplanation:
$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/
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/

Show Answer

Question: 4

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 namedadamin thesafenamespace.

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 namesnewsecretin thesafenamespace, with the following content:

Username:dbadmin

Password:moresecurepas

Finally, create a new Pod that has access to the secretnewsecretvia a volume:

Namespace: safe

Pod name: mysecret-pod

Container name: db-container

Image: redis

Volume name: secret-vol

Mount path: /etc/mysecret

AExplanation:
1. Get the secret, decrypt it & save in files
k get secret adam -n safe -o yaml
2. Create new secret using --from-literal
[desk@cli] $k create secret generic newsecret -n safe --from-literal=username=dbadmin --from-literal=password=moresecurepass
3. Mount it as volume of db-container of mysecret-pod
Explanation

[desk@cli] $k create secret generic newsecret -n safe --from-literal=username=dbadmin --from-literal=password=moresecurepass
secret/newsecret created
[desk@cli] $vim /home/certs_masters/secret-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: mysecret-pod
namespace: safe
labels:
run: mysecret-pod
spec:
containers:
- name: db-container
image: redis
volumeMounts:
- name: secret-vol
mountPath: /etc/mysecret
readOnly: true
volumes:
- name: secret-vol
secret:
secretName: newsecret
[desk@cli] $k apply -f /home/certs_masters/secret-pod.yaml
pod/mysecret-pod created
[desk@cli] $k exec -it mysecret-pod -n safe -- cat /etc/mysecret/username
dbadmin

[desk@cli] $k exec -it mysecret-pod -n safe -- cat /etc/mysecret/password
moresecurepas

Show Answer

Question: 5

Context:

Cluster:prod

Master node:master1

Worker node:worker1

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

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

Task:

Analyse and edit the given Dockerfile (based on theubuntu:18:04image)

/home/cert_masters/Dockerfilefixing two instructions present in the file being prominent security/best-practice issues.

Analyse and edit the given manifest file

/home/cert_masters/mydeployment.yamlfixing two fields present in the file being prominent security/best-practice issues.

Note:Don't add or remove configuration settings; only modify the existing configuration settings, so that two configuration settings each are no longer security/best-practice concerns.

Should you need an unprivileged user for any of the tasks, use usernobodywith user id65535

AExplanation:
1. For Dockerfile:Fix the image version & user name in Dockerfile
2. For mydeployment.yaml : Fix security contexts
Explanation
[desk@cli] $vim /home/cert_masters/Dockerfile
FROM ubuntu:latest # Remove this
FROM ubuntu:18.04 # Add this
USER root # Remove this
USER nobody # Add this
RUN apt get install -y lsof=4.72 wget=1.17.1 nginx=4.2
ENV ENVIRONMENT=testing
USER root # Remove this
USER nobody # Add this
CMD ['nginx -d']

[desk@cli] $vim/home/cert_masters/mydeployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
creationTimestamp: null
labels:
app: kafka
name: kafka
spec:
replicas: 1
selector:
matchLabels:
app: kafka
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
app: kafka
spec:
containers:
- image: bitnami/kafka
name: kafka
volumeMounts:
- name: kafka-vol
mountPath: /var/lib/kafka
securityContext:
{'capabilities':{'add':['NET_ADMIN'],'drop':['all']},'privileged': True,'readOnlyRootFilesystem': False, 'runAsUser': 65535} # Delete This
{'capabilities':{'add':['NET_ADMIN'],'drop':['all']},'privileged': False,'readOnlyRootFilesystem': True, 'runAsUser': 65535} # Add This
resources: {}
volumes:
- name: kafka-vol
emptyDir: {}
status: {}
Pictorial View:
[desk@cli] $vim/home/cert_masters/mydeployment.yaml

Show Answer

Linux Foundation CKS Quiz:13 Topic:1 Questions:61-65