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.
Few days back I wrote a blog about adding new node to the cluster using the static token file. The problem with that approach is that you need to restart kube-apiserver providing it the path to the token file. Here we will see how to use the bootstrap token, which is very dynamic in nature and can be controlled by using Kubernetes resources like secrets. So if you are following Kubernetes the Hard Way to set up the cluster here are the changes you should do to adapt it to run with bootstrap token.
I enabled PodSecurityPolicy on a minikube cluster by appending PodSecurityPolicy to the apiserver flag in minikube like this: –extra-config=apiserver.enable-admission-plugins=Initializers,NamespaceLifecycle,\ LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,\ NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,\ ResourceQuota,PodSecurityPolicy Ideally when you have PSP enabled and if you don’t define any PSP and authorize it with right RBAC no pod will start in the cluster. But what I saw was that there were some pods still running in kube-system namespace. $ kubectl -n kube-system get pods NAME READY STATUS RESTARTS AGE coredns-576cbf47c7-g2t8v 1⁄1 Running 4 5d11h etcd-minikube 1⁄1 Running 2 5d11h heapster-bn5xp 1⁄1 Running 2 5d11h influxdb-grafana-qzpv4 2⁄2 Running 4 5d11h kube-addon-manager-minikube 1⁄1 Running 2 5d11h kube-controller-manager-minikube 1⁄1 Running 1 4d20h kube-scheduler-minikube 1⁄1 Running 2 5d11h kubernetes-dashboard-5bb6f7c8c6-9d564 1⁄1 Running 8 5d11h storage-provisioner 1⁄1 Running 7 5d11h Which got me thinking what is wrong with the way PSPs work.
I passed CKA exam with 92% marks on 19th October 2018. A lot of folks are curious about how to prepare and what resources to follow. Here is my list of things to do and list of resources that might help you on successful CKA exam. The duration of exam is three hours, which is enough time if you do good practice. The exam is pretty straight forward and tests your Kubernetes hands-on knowledge, so whatever you read please try to do it on a real cluster.
The setup here is created by following Kubernetes the Hard Way by Kelsey Hightower. So if you are following along in this then do all the setup till the step Bootstrapping the Kubernetes Worker Nodes. In this just don’t start the kubelet, start other services like containerd and kube-proxy. master node Following the docs of TLS Bootstrapping, let’s first create the token authentication file. Create a file with following content:
To setup a multi-node Kubernetes cluster just run this script and you will have a cluster with 3 masters and 3 workers. $ kubectl get nodes -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME worker-0 Ready <none> 1h v1.11.2 192.168.199.20 <none> Ubuntu 18.04.1 LTS 4.15.0-33-generic cri-o://1.11.2 worker-1 Ready <none> 1h v1.11.2 192.168.199.21 <none> Ubuntu 18.04.1 LTS 4.15.0-33-generic cri-o://1.11.2 worker-2 Ready <none> 1h v1.11.2 192.168.199.22 <none> Ubuntu 18.
Start a single node fedora machine, using whatever method but I have used this Vagrantfile to do it:
-- mode: ruby -- # vi: set ft=ruby : Vagrant.configure("2") do |config| config.vm.define "fedora" do |fedora| fedora.vm.box = "fedora/28-cloud-base" config.vm.hostname = "fedora" end config.vm.provider "virtualbox" do |virtualbox, override| virtualbox.memory = 4096 virtualbox.cpus = 4 end config.vm.provision "shell", privileged: false, inline: <<-SHELL echo ‘127.0.0.1 localhost’ | cat - /etc/hosts > temp && sudo mv temp /etc/hosts SHELL end Now start it and ssh into it:
This post will demonstrate how Kubernetes HostPath volumes can help you get access to the Kubernetes nodes. Atleast you can play with the filesystem of the node on which you pod is scheduled on. You can get access to other containers running on the host, certificates of the kubelet, etc. I have a 3-master and 3-node cluster and setup using this script, running in a Vagrant environment. All the nodes are in ready state:
There is no easy way to change namespace in Kubernetes using kubectl command line utility. But here are some commands that you can alias in your bashrc file so that it’s just a single command that you can use to change the namespace in the Kubernetes cluster. Change namespace Let’s see step by step what goes in to change the namespace. So the first step is to find the context.