Find out what key areas should be taken into consideration when it comes to securing your Kubernetes deployment.
Security in your infrastructure should be considered as a key thing. Depending on the type of your business, your requirements can be more or less tightened, but you always should keep an eye on it.
Same goes for Kubernetes. There are many possibilities to keep your cluster secured. Probably using all of them is not always the best idea, but at least be aware of the below mentioned:
Authorization / Authentication
We have two types of authorization and authentication in Kubernetes.
Firstly, for our application workload we should use Service Accounts (SA) object (and related to it Role, RoleBinding, ClusterRole, ClusterRoleBinding). To be more precise, we are forced to use service account, but implicit usage of SA ends up with admin privileges. This is the thing that we should get rid of as soon as possible. Roles bind to the Service Account should be as narrow as possible.
On the other hand, there are operators, developers, admins. And this is a place where the OICD provider should come into play. There are other ways, like file based authentication, but it should not be considered.
You should never use container images from untrusted source. Please keep in mind that ANYONE can put containers to docker hub main repository. Admins should have a full control of what containers are used in the cluster. To accomplish it use the private repository (like jfrog Artifactory, Nexus etc) and take advantage of remote (proxy) repository and mirrors configuration in docker. To be even more secured, use image scanning tool like Xray. Run your containers in context of non root user.
One of the drawbacks of the docker container is its ability to use Host resources. For example, you can create a pod with mounted docker socket from the host. Let’s imagine what would happen if a docker rm $(docker ps -a -q) command is executed by accident (bug) or deliberate action (malicious user).
To mitigate the above danger, you can consider:
- Using Pod Security Policy
- Using AppArmor (with combination with PSP)
- Use another, more secured container runtime (only for advantage users)
Exposing services to the world
You should take into consideration whether your services are exposed to public or not. In case of public usage you can think about placing those services on separate nodes.
Keep an eye on each master node component. Keep it secure according to official k8s installation guide.
Kubernetes has a secret object which was designed (or rather was supposed to) to keep your configuration secured. Using it you must be aware that it’s only base64 encoded. So it can be easily decoded by any user having permission to read secrets or perform exec to your pod.
To mitigate this security issue, you can use encryption providers.
You can use Network Policy object to restrict traffic inside Kubernetes cluster.
You may consider introducing one of the service mesh solution in your cluster. Istio is one of the most popular. Among others, it brings you end to end ssl support.