In this new post of our blog, we bring you a guide to security practices that complements our last post on “Introduction to Kubernetes – Container Orchestrator ”, with the aim that your team has more clarity about the security considerations for the orchestrator from containers.
The guidelines that we present here are reference guides and should not be considered as all the necessary practices in terms of security:
Table of Contents
Kubernetes Security Scanner With Kube-Bench
This is a resource used to eliminate around 95% of configuration defects, generating quite specific guidelines to guarantee the configuration of your computer network through the application of the Kubernetes benchmark.
Kube Bench is recommended to run first before trying any other method.
Firewall Ports:
This security practice is frequently used since it is not at all advisable to expose a port that does not need to be exposed. To prevent this from happening, there is an ideal order to define the port exposure:
- The first thing you should do is check the existence of an interface or define an IP to link the service, if possible
127.0.0.1
. But in case it is not possible to listen on an interface or IP, you should cut off the port. - Some processes are opening so many ports on all interfaces that they should rather have a public access firewall. Although they only allow purely confidential information, they also allow you direct access to your computer set.
Private Topology:
If your infrastructure will allow you to have private network interfaces, it is recommended to host the cluster of servers in a private subnet and only port forward from your cluster to the NAT gateway.
There is also the case that it may be connected through a cloud provider such as Amazon Web Services (AWS). This procedure is achieved through a VPC (virtual private cloud).
Kubernetes Dashboard:
The dashboard plugin in Kubernetes offers the option to receive a service account in which you can view the entire operation of your computer network with full access.
The challenge with the Kubernetes dashboard is restricting public access to it. In February 2018 it was widely known that the company Tesla had poorly secured its Kubernetes dashboard causing its resources to be used to mine cryptocurrencies (cryptojacking).
Restrict “Docker Image Pull”:
Docker is a resource that can sometimes get out of control due to its ease of access. That is, anyone with access to the Kubernetes API or Docker connector can obtain the image of their choice, generating traffic of infected images or those with serious security problems for Kubernetes.
Even many clusters have already become a network of Bitcoin miners. Although it is a problem that seems to be impossible to solve, the Image Policy plugin can considerably improve this situation by connecting directly to the Docker API.
This plugin imposes a series of strict security rules that reflect a black-and-white list of images that can be extracted and those that cannot.
Another solution applicable to these problems is the “Image Policy Webhook” through “Admission Controller”, which intercepts all image extractions and takes care of security in the same way that the plugin mentioned above does.
Bastion Host:
This means that access to the remote security management protocol (SSH) should not be provided publicly. Instead, you can use a host bastion configuration that exposes SSH only on a specific host.
There are also ways to harden the management protocol using other methods which you can check out in “Hardening OpenSSH” and in the “OpenSSH” chapter of “Applied Crypto Hardening” on bettercrypto.org.
API Authorization Mode And Anonymous Authentication:
The AlwaysAllow authorization method for the cluster, used by most installers such as Kops, would always allow any entity that is authorized and authenticated full access to the cluster. The opposite happens with role-based access control (RBAC).
It is necessary that you know what authorization mode your system is using. You can do this by checking the parameters, where you can also check that authentication is not set to anonymous. If so, you can disable it using “--anonymous-auth = false
”.
It is important to know that this will not affect Kubelet authorization mode in any way, as it exposes an API of its own that executes commands that Kubelet can completely ignore.
More specifically, Kubelet provides a command API used by kubi-apiserver, in which arbitrary commands are executed on a specific node. This configuration can be styled as follows: “--authorization-mode = Webhook
” and “--anonymous-auth = false
”.
Auto Mount Default Service Account:
Default service accounts are a dependency of the admission controller. This ensures that the credentials for this service can be viewed on a container file system running on the pod, as long as the automount feature is active.
This deployed token is also used to display the Kubernetes API configuration.
AWS Metadata API:
This tool is exclusive for use by Amazon Web Services, in which IAM (Identity and Access Management) role credentials are queried through firewall access to the EC2 (Amazon Elastic Compute Cloud) metadata API.
Cloud Provider Host Privileges:
If you are using your cluster on some cloud provider (maybe AWS), you need to know that by default pods inherit privileges from Kubernetes nodes. That’s why if you have policies in place that allow Amazon Elastic Compute Cloud to manage your AWS resources, know that the pod is also allowed to do so.
Use Network Policies:
Network policies represent a series of firewall rules for Kubernetes. Therefore, it is good that you consult the Kubernetes network policies to configure them correctly from the beginning.
See the Kubernetes networking policy for a great starting point. If your network provider doesn’t support network policies, consider switching to one that does, check out.
Be the first to write a comment.