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

Given an existing Pod named test-web-pod running in the namespace test-system

Edit the existing Role bound to the Pod's Service Account named sa-backend to only allow performing get operations on endpoints.

Create a new Role named test-system-role-2 in the namespace test-system, which can perform patch operations, on resources of type statefulsets.

ACreate a new RoleBinding named test-system-role-2-binding binding the newly created Role to the Pod's ServiceAccount sa-backend.

Show Answer

Question: 4

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 namespaceprodand 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 beprivilegedin any way must be treated as potentially not stateless or not immutable.

AExplanation:
k get pods -n prod
k get pod -n prod -o yaml | grep -E 'privileged|ReadOnlyRootFileSystem'
Delete the pods which do have any of these 2 properties
privileged:trueorReadOnlyRootFileSystem: false
[desk@cli]$k get pods -n prod
NAME READY STATUS RESTARTS AGE
cms 1/1 Running 0 68m
db 1/1 Running 0 4m
nginx 1/1 Running 0 23m
[desk@cli]$k get pod nginx -n prod -o yaml | grep -E 'privileged|RootFileSystem'
{'apiVersion':'v1','kind':'Pod','metadata':{'annotations':{},'creationTimestamp':null,'labels':{'run':'nginx'},'name':'nginx','namespace':'prod'},'spec':{'containers':[{'image':'nginx','name':'nginx','resources':{},'securityContext':{'privileged':true}}],'dnsPolicy':'ClusterFirst','restartPolicy':'Always'},'status':{}}
f:privileged: {}
privileged:true

[desk@cli]$k delete pod nginx -n prod
[desk@cli]$k get pod db -n prod -o yaml | grep -E 'privileged|RootFilesystem'

[desk@cli]$k delete pod cms -n prod

Reference:https://kubernetes.io/docs/concepts/policy/pod-security-policy/
https://cloud.google.com/architecture/best-practices-for-operating-containers

Show Answer

Question: 5

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 namedweb-podrunning in the namespacedatabase.

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

2. Create a new Role namedtest-role-2in the namespacedatabase, which only allows performingupdateoperations, only on resources of typestatuefulsets.

3. Create a new RoleBinding namedtest-role-2-bindbinding the newly created Role to the Pod's ServiceAccount.

Note: Don't delete the existing RoleBinding.

AExplanation:
$k edit role test-role -n database
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
creationTimestamp: '2021-06-04T11:12:23Z'
name: test-role
namespace: database
resourceVersion: '1139'
selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/database/roles/test-role
uid: 49949265-6e01-499c-94ac-5011d6f6a353
rules:
- apiGroups:
- ''
resources:
- pods
verbs:
- * # Delete
- get # Fixed
$k create role test-role-2 -n database --resource statefulset --verb update
$k create rolebinding test-role-2-bind -n database --role test-role-2 --serviceaccount=database:test-sa
Explanation
[desk@cli]$k get pods -n database
NAME READY STATUS RESTARTS AGE LABELS
web-pod 1/1 Running 0 34s run=web-pod
[desk@cli]$k get roles -n database
test-role
[desk@cli]$k edit role test-role -n database
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
creationTimestamp: '2021-06-13T11:12:23Z'
name: test-role
namespace: database
resourceVersion: '1139'
selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/database/roles/test-role
uid: 49949265-6e01-499c-94ac-5011d6f6a353
rules:
- apiGroups:
- ''
resources:
- pods
verbs:
- '*' # Delete this
- get # Replace by this
[desk@cli]$k create role test-role-2 -n database --resource statefulset --verb update
role.rbac.authorization.k8s.io/test-role-2 created

[desk@cli]$k create rolebinding test-role-2-bind -n database --role test-role-2 --serviceaccount=database:test-sa
rolebinding.rbac.authorization.k8s.io/test-role-2-bind created

Reference:https://kubernetes.io/docs/reference/access-authn-authz/rbac/
role.rbac.authorization.k8s.io/test-role-2 created
[desk@cli]$k create rolebinding test-role-2-bind -n database --role test-role-2 --serviceaccount=database:test-sa
rolebinding.rbac.authorization.k8s.io/test-role-2-bind created
[desk@cli]$k create role test-role-2 -n database --resource statefulset --verb update
role.rbac.authorization.k8s.io/test-role-2 created

[desk@cli]$k create rolebinding test-role-2-bind -n database --role test-role-2 --serviceaccount=database:test-sa
rolebinding.rbac.authorization.k8s.io/test-role-2-bind created

Reference:https://kubernetes.io/docs/reference/access-authn-authz/rbac/

Show Answer

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