H 143: Exploring Pods (10 pts)

What You Need for this Project

A Linux machine--I used a Google Cloud Debian 12 headless server

Purpose

To set up a Kubernetes cluster and deploy a containerized application.

I am following this tutorial: Kubernetes Bootcamp (CKAD).

Preparation

First do the previous project, "Hello Kubernetes".

Starting Minikube

On your Linux server, execute these commands:


minikube start

Your cluster starts, showing several messages, ending with "Done! kubectl is now configured...", as shown below.

Troubleshooting
If minkube just hangs and won't start, press Ctrl+C and execute these commands:
minikube delete
minikube start

Examining minikube Status

On your Linux server, execute these commands:


minikube status

You should see several "Running" items, as shown below.

States of Pods and Containers

Whilst a Pod is running, the kubelet is able to restart containers to handle some faults. Within a Pod, Kubernetes tracks different container states and determines what action to take to make the Pod healthy again.

Kubernetes tracks the phase of a Pod

Pending - Pod starts here and waits to be scheduled, image download, etc
Running - at least one container running
Succeeded - all containers terminated successfully
Failed - all containers have terminated, at least one terminated in failure
Unknown - pod state cannot be obtained, either node communication breakdown or other

Kubernetes also tracks the state of containers running in a Pod

Waiting - startup not complete
Running - executing without issues
Terminated - ran into issues whilst executing

Creating a Pod Incorrectly with the mysql Image

Execute these commands:


kubectl run mydb --image=mysql --dry-run=client -o yaml > db1.yaml
kubectl apply --filename db1.yaml
kubectl get pods
kubectl describe --filename db1.yaml | less

The first screen of data shows that the pod has been crashing, with Restart Count rising and a Reason of "CrashLoopBackOff", as shown below:

Press the SPACEBAR until you reach the end of the output.

The Events show several "Successfully pulled image" messages, but the time between them keeps increasing, as shown below.

This is what the "CrashLoopBackOff" does.

Press q to exit from "less."

Watching Pods

Execute these commands:


kubectl run mydb --image=mysql --dry-run=client -o yaml > db1.yaml
kubectl apply --filename db1.yaml
kubectl get pods
kubectl describe --filename db1.yaml | less

Viewing Pod Information

Execute this command:


kubectl get pods --watch

You see a live view of the pod status.

If you wait for a few minutes, you should see the status change when the pod restarts, as shown below.

Press Ctrl+c to stop the watch view.

Creating a Pod Correctly with the mysql Image

The pod above is crashing because we did not specify a MySQL password.

Execute these commands:


kubectl delete --filename db1.yaml

kubectl run mydb --image=mysql --env="MYSQL_ROOT_PASSWORD=secret" \
  --dry-run=client -o yaml > db2.yaml

kubectl apply --filename db2.yaml
kubectl get pods
kubectl describe --filename db2.yaml | less

The first screen of data shows that the pod has a Status of "Running", as shown below.

(If it shows "Pending", wait a minute and try again.)

The Events show one "Pulling image" action, without any crashing and restarting, as shown below:

Cleaning Up

Execute this command:


kubectl delete --filename db2.yaml

Security Context

A security context defines privilege and access control settings for a Pod or Container. Security context can be controlled at Pod-level pod.spec.securityContext as well as at container-level pod.spec.containers.securityContext.

Here are some important security context parameters:

runAsNonRoot    $boolean - specifies whether the containers run as a non-root user at image level - containers will not start if set to true while image uses root (pod and container)

runAsUser    $UID - sspecifies the UID of logged-in user in pod containers (pod and container)

fsGroup    $GID - specifies additional GID used for filesystem (mounted volumes) in pod containers (pod level)

privileged    $boolean - controls whether containers will run as privileged or unprivileged (container level)

allowPrivilegeEscalation    $boolean - controls whether a process can gain more privileges than its parent process - always true when the container is run as privileged, or has CAP_SYS_ADMIN (container level)

readOnlyRootFilesystem    $boolean - controls whether the container has a read-only root filesystem (container level)

You can see complete information about these settings by executing these commands:


kubectl explain pod.spec.securityContext | less

kubectl explain pod.spec.containers.securityContext | less

Using the Official Manifest Example

Execute these commands to download an example YAML file and view it:


wget https://kubernetes.io/examples/pods/security/security-context.yaml
cat security-context.yaml

Notice the "securityContext" settings, highlighted in the image below.

Execute these commands to create a pod based on the "security-context.yaml" file and examine its security properties:


kubectl apply --filename security-context.yaml
kubectl get pods
kubectl exec -it security-context-demo -- sh

whoami
id 
cat /etc/passwd

The user inside the container is "unknown" and has uid 1000, as shown below.

To see why this user is "unknown", execute this command:


cat /etc/passwd

This pod is based on "busybox," and doesn't have an actual user 1000 in its /etc/passwd file, as shown below.

You can use the system as this user, but there's no way to log in with this account--a strange situation!

Viewing Running Processes

Execute this command to see running processes:

ps

Several processes are running under the uid 1000, as shown below.

Using the /data Directory

Execute these commands to see the permissions of the /data/demo directory, create a file there, and view its permissions.


ls -l /data
touch /data/demo/new-file
ls -l /data/demo

As shown below, the /data/demo directory has permissions rwxrwxrwx, meaning everyone can read and write there.

The file you created is owned by your current user, 1000.

Attempting Privilege Escalation

Execute this commmand to try to get root permissions:


sudo su

As shown below, there is no "sudo" executable in this image, so you're stuck with limited privileges.

Cleaning Up

Execute these commands:


exit
kubectl delete pod security-context-demo

The pod is gone, as shown below.

Editing the Manifest File

Execute this commmand:


nano security-context.yaml

Adjust the securityContext section, as shown below, to:


    runAsNonRoot: true
    fsGroup: 2000

To save the file, press Ctrl+x, y, Enter.

Creating a Pod

Execute these commands to create a pod based on the "security-context.yaml" file and examine its status:


kubectl apply --filename security-context.yaml
kubectl get pods

There's a configuration error, as shown below.

To learn about the error, execute this command:


kubectl describe pods security-context-demo

The problem is that you cannot set "runAsNonRoot" without specifying a non-root user with the "runAsUser: $UID" line, as shown below.

Flag H 143.1: Reason (10 pts)
The flag is covered by a green rectangle in the image above.

Cleaning Up

Execute these commands:


kubectl delete pod security-context-demo
kubectl get pods

The pod is gone, as shown below.

References

Kubernetes Bootcamp (CKAD)
Running Docker Containers as a Non-root User with a Custom UID / GID

Posted 4-17-25

runAsNonRoot		$boolean - specifies whether the containers run as a non-root user at image level - containers will not start if set to true while image uses root (pod and container)
runAsUser		$UID - sspecifies the UID of logged-in user in pod containers (pod and container)
fsGroup		$GID - specifies additional GID used for filesystem (mounted volumes) in pod containers (pod level)
privileged		$boolean - controls whether containers will run as privileged or unprivileged (container level)
allowPrivilegeEscalation		$boolean - controls whether a process can gain more privileges than its parent process - always true when the container is run as privileged, or has CAP_SYS_ADMIN (container level)
readOnlyRootFilesystem		$boolean - controls whether the container has a read-only root filesystem (container level)