Containers

This blog shows a simple set of commands to install a Kubernetes cluster on Flatcar Container Linux based machines using Kubeadm. You might wonder why this blog when one can go to the official documentation and follow the steps? Yep, you are right. You can choose to do that. But this blog has a collection of actions specific to Flatcar Container Linux. These steps have been tried and tested on Flatcar, so you don’t need to recreate and test them yourself....

If you use exec in your container script, then the container or Kubernetes pod might exit after the command that is exec-ed into has exited. But if that’s what you wanted, then it’s okay. This blog tries to explain how to pass the signals to the applications, how they work differently when invoked uniquely and what to do if the application does handle them. What are the “Signals”? Signals are messages one process can send to another process, mostly used in UNIX like operating systems....

Introduction For the reasons of security, many container deployments nowadays run their workloads in a scratch based image. This form of implementation helps reduce the attack surface since there is no shell to gain access to, especially if someone were to break out of the application. But for the developers or operators of such applications, it is hard to debug. Since they lack essential tools or even bash for that matter, but the application’s debugging ability should not dictate its production deployment and compromise its security posture....

File capabilities allow users to execute programs with higher privileges. Best example is network utility ping. A ping binary has capabilities CAP_NET_ADMIN and CAP_NET_RAW. A normal user doesn’t have CAP_NET_ADMIN privilege, since the executable file ping has that capability you can run it. $ getcap `which ping` /usr/bin/ping = cap_net_admin,cap_net_raw+p Which normally works as follows: $ ping -c 1 1.1.1.1 PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. 64 bytes from 1....

Here are simple steps that you can follow to prove that the root user inside container is also root on the host. And how to mitigate this. Root in container, root on host I have a host with docker daemon running on it. I start a normal container on it with sleep process as PID1. See in the following output that the container clever_lalande started with sleep process. $ docker run -d --rm alpine sleep 9999 6c541cf8f7b315783d2315eebc2f7dddd1f7b26f427e182f8597b10f2746ab0b $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 6c541cf8f7b3 alpine "sleep 9999" 12 seconds ago Up 11 seconds clever_lalande Now let’s find out the process sleep on the host....

This blog shows you how you can copy stuff from your host machine to the running container without the docker cp command that we usually use. Steps in text Here I have a script on the host, which looks following: #!/bin/bash tput bold echo "OS Information:" tput sgr0 echo cat /etc/os-release After running which looks like following: $ ls script.sh $ ./script.sh OS Information: NAME="Flatcar Linux by Kinvolk" ID=flatcar ID_LIKE=coreos VERSION=2079....

I am doing Kubernetes native development using minikube. And for doing that I had to download a Container image that is available in internally hosted private container registry. On the configuration side of doing that you will need to create Kubernetes Secret of type docker-registry. And now refer that secret you just created in your Pod manifest under pod.spec.imagePullSecrets. For more info follow the tutorial in Kubernetes docs on Pull an Image from a Private Registry....