Great CKS Kubernetes Security Exam preparation guide to help you pass

 Recapping how was my exam, and the study process I followed, so it can help you pass too

If at first you don’t succeed, Just keep trying.

I hope to share my exam experience, offer some study tips and resources as well as offer some insights into your very own exam ReadinessProbe (You see what I did there?)

What Is the Certified Kubernetes Security Specialist Exam?

According to the CNFC, the CKS Exam “provides assurance that a CKS has the skills, knowledge, and competence on a broad range of best practices for securing container-based applications and Kubernetes platforms during build, deployment and runtime.”

With a great number of features that are available in the vanilla standalone Kubernetes versus the managed service offering, you earn a great deal of SecOps brownie points by staying on top of the security posture of your Kubernetes Cluster, whatever the cloud platform.

The Certified Kubernetes Administrator certification is a prerequisite for the Certified Kubernetes Security Certification. As you likely have seen through the Kubernetes documentation, there is a great amount of implementation detail in every aspect of admission control, advanced policies, and never-ending custom resource definitions, which can be created and managed by third parties

This certification is yet another great opportunity to validate your skills and knowledge, which now has security as an integral part of the Kubernetes focused certification track.

SIGN UP FOR EXAM

It is a personal challenge to wrap up the CNCF Kubernetes Certification track [CKA,CKAD and now CKS]. That and Containerisation and Service Mesh are my keen area of on-going interest.

Exam Experiences

From my point of view, this was a tough-but-fair certification accomplishment.

I have been working in Kubernetes and containerisation for around three years, with recent work effort in service mesh implementation. The CKA, being a pre-requisite for the CKS exam, provides a great foundational framework to get started with.

This certification not only covers general kubernetes cluster administration knowledge, but there’s also a certain degree of depth particularly in self-managed master api-server configuration you should be well versed in.

The exam material brings together the security best practices of the Dockerfile manifest management as well as static (SAST), and runtime (DAST) vulnerability assessment and prevention. Interestingly, some of the tools featured are developed by teams and vendors outside the immediate kubernetes configuration ecosystem. This is why this is a great all rounder of certification and should seriously be considered for senior professionals working in this space.

I’ve written a number of blog posts in the past which touch on some of the CKS tested elements like Taints & Toleration [Why separate your Kubernetes workload with nodepool segregation and affinity options] and Cluster Network Security posts in particular. Finally, from a Service Mesh perspective — a tad more advanced but good-to-know if you want to dive deeper on the topic.
And if you want to dive deeper with KubeCon and ServiceMeshCon, I have recently covered the best key conference takeaway notes here, and deeper-yet on GitOps, here.

Exam Prep

The exam prep to be a great validator of existing knowledge, and highlight the areas which, while not used regularly, such as Pod Security Policies, was found to be most helpful to clarify and learn the gaps for.

The depth and breadth of the exam knowledge is sensible with the following areas covered to a great degree:

• Best Practice Docker Image development and Docker Framework model
• Knowledge of the following particular set of tools (e.g. CIS Kube-bench, Trivy, Sysdig/Falco, AppArmor, Seccomp, OPA/Gatekeeper)
• Extensive API Server familiarity including debugging of issues, in both extension and tuning (Admission control, Audit)
• Knowledge of linux fundamentals, particular to security with cGroup mapping is desired — fantastic blog link for more details
• A thorough knowledge of Kubernetes Architecture and component interaction (RBAC, NetworkPolicies, PSP, etc.)

Study Resources

I have found the following resources extremely helpful preparing for the CKS exam. Start with videos over weekend, easier to get into the study mode. Follow-up by the reading material. you can mix and match that as it works better.

Videos to consume, and get into the study zone:

• Kubernetes Security Best Practices 101​ — Youtube Video​
• Secure Your Containers — Youtube Video​
• Getting to Grips with Kubernetes RBAC — Youtube Video​​
• Using effective RBAC — Youtube Video​​
• Understanding Pod security policies — Youtube Video​​
• Intro to Falco — Youtube Video​
• Intro to Secomp — Youtube Video​

Supplemental Reading Material:

• Network policies editor by Cillium Networks — amazing visual representation and creation of network policies on this one!​
• Kubernetes Pentest Methodology 2019 — but still relevant, great post​ to read
• Securing Kubernetes Clusters — Eliminate Risky Permissions​
• Full CKS Udemy course By Kim​
• Cluster Security Best Practices — Medium Post​
• StackRox CKS study guide​
• Awesome CKS notes by EchoBoomer​

Practice exam with the CKS exam Sim:

• CKS exam simulator — Killer.sh​

Main Exam Tips

• Take care with time keeping
  The exam does not have a countdown timer, which would be extremely helpful. There is a time bar, but it’s hard to assess where it is at, we’re used to seeing the actual time remaining after all.
• Watch out for question/exam environment bugs
  I wish I could say it was straight forward questions, but be prepared to have an exam window crash, exam restarted and, worse, some questions will be referring to question components incorrectly named. i.e. “Allow” versus “Ally”, if in doubt IMO save it with both names.

Kubernetes-native exam material

• Admission controllers
  Ensure you are familiar with different types such as PodSecurityPolicy and ImagePolicyWebhook. Implement and understand how they work with the API server and how they can provide added security to the cluster. https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/
• Immutable containers
  Find ways to make containers immutable using securitycontext and avoid mutable configuration, such as allowing shell access to a container. Immutable containers are good as we always know the state!
• NetworkPolicies
For extra security and more control over traffic flowing between pods use Network Policies. By default all pods in a cluster can talk to each other, get more granular and create specific rules to define traffic flow.
• PodSecurityPolicies*
  This enables fine-tuned resource authorisation. This could be one of greatest assets in secure workload runtime. (This is be deprecated* soon in favour of OPA, some blog post read on this)​
  https://kubernetes.io/docs/concepts/policy/pod-security-policy/
• gVisor — Kernel Sandbox
  This is a kernel sandboxing and abstraction implementation, helping prevent malicious applications and images from overloading the underlying Host machine Kernel.
  ​

Third-Party Tools Examinable material

The following are mentioned thoroughly in the CKS criteria.

These are some examples of open source tools and projects, outside the immediate kubernetes ecosystem that are recommended to get hands-on with in order to successfully pass the exam.

• AquaSec OpenSource Kube-Bench
  Easy to execute against your cluster. Pull down binaries on worker (and master) nodes and run the binary kube-bench worker|master to have your cluster inspection report. This would be a great starting point.
• Aquasec/trivy
  Image scanning tool — is a very simple image scanning tool.
• AppArmor
  Practice loading new profiles and then using it with your pods. AppArmor would be pre-installed.
• Falco
  Practice finding all falco rules and search for specific ones and change their output and capture specific output.

Start with — Booking that Exams

If you’re anything like me, you will probably organise your time schedule to ensure you sit the exam, by booking the exam first. Remember that pre-requisite is the CKA certification.

One Final Tip to remember — it’s an open book exam. BUT you wont have time to start “searching” for answers. You need to already know where to go and get them. Practice that search, and you’ll be fine.

Don’t worry — this is unlikely to happen. You just need to be THAT prepared. :)

Already passed the exam? How did it go, share your experience in the comments section below. In fact, get in touch, you may want to get working on cloud native Kubernetes work stream right away. We’re always hiring!

ITNEXT

ITNEXT is a platform for IT developers & software engineers…

Docker 101: Fundamentals & The Dockerfile

You, like me, may have heard of Docker before. You may have co-workers or developer friends who rave about it, who “dockerize” everything they can, and who are at an utter loss for words when it comes to explaining Docker, and all its glory, in terms that are understandable to the average person. Today, I will attempt to demystify Docker for you.

This will actually be a three-part series on Docker, because Docker needs, at least, three separate posts for its three best known products:

• Docker (and the Dockerfile),
• Docker Compose, and
• Docker Swarm

So let’s begin at the beginning and I’ll explain what Docker actually is, in terms even I understand.

What is Docker?

The Docker website itself simply describes Docker as:

“the world’s leading software containerization platform” — Docker, Docker Overview

That really clears it up, right? Umm…yeah, not really. A much better description of Docker is found on OpenSource.com.

Docker is a tool designed to make it easier to create, deploy, and run applications by using containers. Containers allow a developer to package up an application with all of the parts it needs, such as libraries and other dependencies, and ship it all out as one package. — OpenSource.com, What is Docker?

What Docker really does is separate the application code from infrastructure requirements and needs. It does this by running each application in an isolated environment called a ‘container.’ This means developers can concentrate on the actual code to run in the Docker container without worrying about the system it will ultimately run on, and devOps can focus on ensuring the right programs are installed in the Docker container, and reduce the number of systems needed and complexity of maintaining said systems after deployment.

Which is a perfect segue to the next point: why Docker?

Why Docker?

I can’t tell you how many times I’ve heard a developer (myself included) say, “It works on my machine, I don’t know why it won’t work on yours.” — any developer, ever

This is what Docker is designed to prevent — the inevitable confusion that comes when a dev’s been working on their local machine on a project for days (or weeks), and as soon as it’s deployed to a new lifecycle, the app won’t run. Most likely because there’s a host of installed dependencies that are necessary to run the application but they aren’t saved in the package.json or the build.gradle or specified in the manifest.yml.

Every single Docker container begins as a pure vanilla Linux machine that knows nothing.

The Docker container’s just like Jon Snow when it spins up; it knows nothing.

Then, we tell the container everything it needs to know — all the dependencies it needs to download and install in order to run the application. This process is done with a Dockerfile, but I’m getting ahead of myself.

For this section, suffice it to say, Docker takes away the guesswork (and hours spent debugging) from deploying applications because it always starts as a fresh, isolated machine and the very same dependencies get added to it. Every. Single. Time.

No environments that have different versions of dependencies installed. No environments missing dependencies entirely. None of that nonsense with Docker.

Docker Tools

Before I dive into the Dockerfile, I’ll give a quick run down of Docker’s suite of tools.

Docker has four main tools that it provides to accomplish tasks:

• Docker Engine
• Docker Compose
• Docker Machine*
• Docker Swarm

The Docker Engine is Docker’s

“powerful open source containerization technology combined with a work flow for building and containerizing your applications.” — Docker, About Docker Engine

It’s what builds and executes Docker images from either a single Dockerfile or docker-compose.yml. When someone uses a docker command through the Docker CLI, it talks to this engine to do what needs to be done.

Docker Compose

“is a tool for defining and running multi-container Docker applications” — Docker, Overview of Docker Compose

This is what you use when you have an application made up of multiple microservices, databases and other dependencies. The docker-compose.yml allows you to configure all those services in one place and start them all with a single command. I’ll cover Docker Compose in much greater detail in the follow up blog post.

In years past, Docker Machine was more popular than it is now.

“Docker Machine is a tool that lets you install Docker Engine on virtual hosts, and manage the hosts with docker-machine commands.” — Docker, Docker Machine Overview

It’s fallen by the wayside a bit as Docker images have become more stable on their native platforms, but earlier in Docker’s history it was very helpful. That’s about all you need to know about Docker Machine for now.

The final tool, Docker Swarm, will be covered in detail in blog post 3. But for now, Docker Swarm

“creates a swarm of Docker Engines where you can deploy application services. You don’t need additional orchestration software to create or manage a swarm” — Docker, Swarm Mode Overview

These are the tools you’ll become familiar with, and now, we can talk about the Dockerfile.

The Dockerfile — where it all begins

Docker is a powerful tool, but its power is harnessed through the use of things called Dockerfiles.

A Dockerfile is a text document that contains all the commands a user could call on the command line to assemble an image. Using docker build users can create an automated build that executes several command-line instructions in succession.- Docker, Dockerfile Reference

A Docker image consists of read-only layers each of which represents a Dockerfile instruction. The layers are stacked and each one is a delta of the changes from the previous layer.

This is what I was talking about above, when a Docker container starts up, it needs to be told what to do, it has nothing installed, it knows how to do nothing. Truly nothing.

The first thing the Dockerfile needs is a base image. A base image tells the container what to install as its OS — Ubuntu, RHEL, SuSE, Node, Java, etc.

Next, you’ll provide setup instructions. These are all the things the Docker container needs to know about: environment variables, dependencies to install, where files live, etc.

And finally, you have to tell the container what to do. Typically it will be running specific installations and commands to the application specified in the setup instructions. I’ll give a quick overview of the most common Dockerfile commands next and then show some examples to help it make sense.

Dockerfile Commands

Below, are the commands that will be used 90% of the time when you’re writing Dockerfiles, and what they mean.

• FROM — this initializes a new build stage and sets the Base Image for subsequent instructions. As such, a valid Dockerfile must start with a FROM instruction.
• RUN — will execute any commands in a new layer on top of the current image and commit the results. The resulting committed image will be used for the next step in the Dockerfile.
• ENV — sets the environment variable <key> to the value <value>. This value will be in the environment for all subsequent instructions in the build stage and can be replaced inline in many as well.
• EXPOSE — informs Docker that the container listens on the specified network ports at runtime. You can specify whether the port listens on TCP or UDP, and the default is TCP if the protocol is not specified. This makes it possible for the host and the outside world to access the isolated Docker Container
• VOLUME — creates a mount point with the specified name and marks it as holding externally mounted volumes from the native host or other containers.

Ok, now Dockerfile commands have been defined, so let’s look at some sample Dockerfiles. If you want to learn more about Docker commands, I’d highly recommend the Dockerfile documentation — it’s very well written.

Dockerfile Examples

Here are a few sample Dockerfiles, complete with comments explaining each line and what’s happening layer by layer.

Node Dockerfile Example

# creates a layer from the node:carbon Docker image
FROM node:carbon# create the app directory for inside the Docker image
WORKDIR /usr/src/app# copy and install app dependencies from the package.json (and the package-lock.json) into the root of the directory created above
COPY package*.json ./
RUN npm install# bundle app source inside Docker image
COPY . .# expose port 8080 to have it mapped by Docker daemon
EXPOSE 8080# define the command to run the app (it's the npm start script from the package.json file)
CMD [ "npm", "start" ]

Java Dockerfile Example

# creates a layer from the openjdk:8-jdk-alpine Docker image
FROM openjdk:8-jdk-alpine# create the directory for where Tomcat creates its working directories
VOLUME /tmp# copy the project JAR file to the container renamed as 'app.jar'
COPY build/libs /app# execute that JAR in the entry point below
ENTRYPOINT ["java", "-Djava.security.egd=file:/dev/./urandom", "-jar", "/app/java-example.jar"]

Python Dockerfile Example

# creates a layer from the ubuntu:16.04 Docker image 
FROM ubuntu:16.04# adds files from the Docker client’s current directory
COPY . /app# builds the application with make 
RUN make /app# specifies what command to run within the container
CMD python /app/app.py

Jenkins Dockerfile Example

# creates a layer from the jenkins:lts Docker image
FROM jenkins/jenkins:lts # sets user to root (because Docker always runs as root and Jenkins needs to know this)
  USER root
 
 # add and install all the necessary dependencies
 RUN apt-get update && \
 apt-get install -qy \
   apt-utils \
   libyaml-dev \
   build-essential \
   python-dev \
   libxml2-dev \
   libxslt-dev \
   libffi-dev \
   libssl-dev \
   default-libmysqlclient-dev \
   python-mysqldb \
   python-pip \
   libjpeg-dev \
   zlib1g-dev \
   libblas-dev\
   liblapack-dev \
   libatlas-base-dev \
   apt-transport-https \
   ca-certificates \
   zip \
   unzip \
   gfortran && \
 rm -rf /var/lib/apt/lists/*
 
 # install docker
 RUN curl -fsSL get.docker.com -o get-docker.sh && sh get-docker.sh
 
 # install docker compose
 RUN curl -L https://github.com/docker/compose/releases/download/1.8.0/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose && \
     chmod +x /usr/local/bin/docker-compose # install pip for python
 RUN pip install cffi --upgrade
 RUN pip install pip2pi ansible==2.0
 
 # copy groovy executors and plugins for jenkins and run the plugins
 COPY executors.groovy /usr/share/jenkins/ref/init.groovy.d/executors.groovy
 COPY plugins.txt /usr/share/jenkins/ref/plugins.txt
 RUN /usr/local/bin/plugins.sh /usr/share/jenkins/ref/plugins.txt
 
 # add the jenkins user to the docker group so that sudo is not required to run docker commands
 RUN groupmod -g 1026 docker && gpasswd -a jenkins docker
 USER jenkins

The commands aren’t really that hard or complicated, once you see the files broken down like this.

Images vs. Containers

The terms Docker image and Docker container are sometimes used interchangeably, but they shouldn’t be, they mean two different things.

Docker images are executable packages that include everything needed to run an application — the code, a runtime, libraries, environment variables, and configuration files.

Docker containers are a runtime instance of an image — what the image becomes in memory when executed (that is, an image with state, or a user process).

Examples of Docker containers. Each one comes from a specific Docker image.

In short, Docker images hold the snapshot of the Dockerfile, and the Docker container is a running implementation of a Docker image based on the instructions contained within that image.

We clear? Cool.

Docker Engine Commands

Once the Dockerfile has been written the Docker image can be built and the Docker container can be run. All of this is taken care of by the Docker Engine that I covered briefly earlier.

A user can interact with the Docker Engine through the Docker CLI, which talks to the Docker REST API, which talks to the long-running Docker daemon process (the heart of the Docker Engine). Here’s an illustration below.

The CLI uses the Docker REST API to control or interact with the Docker daemon through scripting or direct CLI commands. Many other Docker applications use the underlying API and CLI as well.

Here are the commands you’ll be running from the command line the vast majority of the time you’re using individual Dockerfiles.

• docker build — builds an image from a Dockerfile
• docker images — displays all Docker images on that machine
• docker run — starts container and runs any commands in that container
• there’s multiple options that go along with docker run including
• -p — allows you to specify ports in host and Docker container
• -it—opens up an interactive terminal after the container starts running
• -v — bind mount a volume to the container
• -e — set environmental variables
• -d — starts the container in daemon mode (it runs in a background process)
• docker rmi — removes one or more images
• docker rm — removes one or more containers
• docker kill — kills one or more running containers
• docker ps — displays a list of running containers
• docker tag — tags the image with an alias that can be referenced later (good for versioning)
• docker login — login to Docker registry

These commands can be combined in ways too numerous to count, but here’s a couple simple examples of Docker commands.

docker build -t user1/node-example .

This says to Docker: build (build) the image from the Dockerfile at the root level ( . ) and tag it -t as user1/node-example. Don’t forget the period — this is how Docker knows where to look for the Dockerfile.

docker run -p 3003:8080 -d user1/node-example

This tells Docker to run (run) the image that was built and tagged as user1/node-example, expose port 3003 on the host machine and look for port 8080 inside the Docker container (-p 3003:8080), and start the process as a background daemon process (-d).

That’s how simple it can be to run commands using the Docker CLI. Once again, the Docker documentation is well done.

Conclusion and Part Two: Docker Compose

Now you’ve seen the tip of the iceberg of Docker. It’s a lightweight, isolated runtime environment known as a ‘container’ that you can spin up and configure just about anyway you like with the help of a Dockerfile.

Stay tuned for part two of this three part series where I’ll dive into the Docker Compose tool that lets you configure and run multiple applications with just one file and a single start command. It’s pretty darn cool.

Thanks for reading, I hope this gives you a better understanding of the basics of Docker and its power. Claps are very much appreciated!

If you enjoyed reading this, you may also enjoy some of my other blogs:

• React, SVG Images and the Webpack Loader to Make Them Play Nice
• JavaScript Array Methods to Make You a Better Developer
• What is GraphQL, really?

References and Further Resources:

• Docker: https://www.docker.com/what-docker
• What is Docker?: https://opensource.com/resources/what-docker
• Dockerfile Documentation: https://docs.docker.com/engine/reference/builder/
• Docker Run Reference: https://docs.docker.com/engine/reference/run/