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.
which ping /usr/bin/ping = cap_net_admin,cap_net_raw+p Which normally works as follows:
$ ping -c 1 184.108.40.206 PING 220.127.116.11 (18.104.22.168) 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.
There are always scripts that you write to automate some mundane tasks. And then you put that script in a directory that is in your PATH. But what this does is that it pollutes your system global PATH and shows up in places you wouldn’t want it to be in.
I was struggling with this issue for a while and struggling to get a proper solution. But there is a very simple and clever trick to solve this problem.
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.
What is Seccomp? A large number of system calls are exposed to every userland process with many of them going unused for the entire lifetime of the process. A certain subset of userland applications benefit by having a reduced set of available system calls. The resulting set reduces the total kernel surface exposed to the application. System call filtering is meant for use with those applications. Seccomp filtering provides a means for a process to specify a filter for incoming system calls.
Hardening Kubernetes by Securing Pods - Rootconf 2019 State of Kubernetes Meetups - DevOpsDays India 2017 Making Kubernetes Simple For Developers - Rootconf 2017 Taking docker-compose to Production - Gophercon 2017 Lightening talk Watch from 55m59s
The Kubernetes Bangalore Meetup was organized at Arvind Internet on Feb 16th 2019. The agenda for the meetup was to teach Kubernetes to the beginners.
Meetup agenda can be found here.
The moments from Meetup:
We go online in sometime here https://t.co/FkwgOx0Tm4
— Kubernetes Bangalore (@k8sBLR) March 16, 2019 .@pmishra1598 kick started the Meetup by explaining what #Kubernetes is! Currently clarifying what a pod is. pic.twitter.com/Ny7bN9c62x
— Kubernetes Bangalore (@k8sBLR) March 16, 2019 Huge turnout at today's meetup it's on 🔥🔥 pic.
If you want to provide extra flags to the kube-apiserver that runs inside minikube how do you do it? You can use the minikube’s –extra-config flag with apiserver.<apiserver flag>=<value>, for e.g. if you want to enable RBAC authorization mode you do it as follows:
–extra-config=apiserver.authorization-mode=RBAC So this is a no brainer when doing it for flags whose value can be given right away, like the one above. But what if you want to provide value which is a file path.
A volume mount CVE was discovered in Kubernetes 1.9 and older which allowed access to node file system using emptyDir volume mount using subpath. The official description goes as follows:
In Kubernetes versions 1.3.x, 1.4.x, 1.5.x, 1.6.x and prior to versions 1.7.14, 1.8.9 and 1.9.4 containers using subpath volume mounts with any volume type (including non-privileged pods, subject to file permissions) can access files/directories outside of the volume, including the host’s filesystem.
If you are using cobra cmd line library for golang applications and it’s PersistentFlags and if you have a use case where you are adding same kind of flag in multiple places. You might burn your fingers in that case, if you keep adding it in multiple sub-commands without giving it a second thought. To understand what is really happening and why it is happening follow along.
All the code referenced here can be found here https://github.