Learn how to Secure a Kubernetes Cluster - CKA Exam Preparation Series

kubernetes kubernetes certification kubernetes engine security kubernetes security Sep 14, 2020
kubernetes security

 

This is one of the numerous posts by TechCommanders in a series for studying for the Certified Kubernetes Administrator (CKA) Exam.

Become a Certified Kubernetes Administrator (CKA)!

Before learning how to secure a Kubernetes Cluster. Let’s read about why it is important to secure a Kubernetes cluster. Last year, somewhere around January the world’s biggest orchestration system, experienced the major security vulnerability that hit the project ecosystem hard.

 

We won’t get much into the vulnerability but would like to provide you with an overview. Using this vulnerability attackers can compromise clusters using API server. This allows them to execute malicious code and put in malware.

 

The other case that we had come across was because of the wrong configuration of Kubernetes cluster which led to the installation of cryptocurrency mining software on tesla resources.

 

One attacker took the advantage of a non-protected Kubernetes Panel by which they were allowed to access the pods and make changes in a larger part of Tesla on AWS.

 

So, the organizations which are using this orchestration system or shifting to this should be aware of the best security practice to support customer data. Follow the following advice to protect your infrastructure.

 

Advice-1: Always be updated
Always keep your systems to the latest version. Kubernetes team provides the new update every quarter that doesn’t only have bug fixes but also a new security measure. So, it is recommended to always use the newest most stable version.

Sometimes, it can be harder to update the system if it has new features or the dependency on an existing project is being changed. But you should schedule a regular update every quarter even if it affects your development hours. A little delay in the product is more worthy than the insecure product.

 

Advice-2: Enable role-based access control (RBAC)
This feature is enabled from Kubernetes version 1.6 and if you are on this version or the later you should enable this feature. This will help you to provide only the required permission to a person and it can also regulate who can access the Kubernetes API.
Enabling RBAC is not sufficient. You have to avoid giving the rights to access the whole cluster(cluster-wide). Also, avoid giving the cluster’s admin permission even for debugging. It’s safer to provide the permissions which are highly needed and keep changing them from time to time.

If the appliance requires the permission of Kubernetes API, try creating a new service account and add a minimum set of the required permission to it. So, this approach is more efficient and better than giving an excessive amount of privilege to the default account.

 

Advice-3: Set boundaries using Namespace
Creating a separate namespace for your cluster is vital as it can be the first level of component isolation. Using namespace will become easier as it will allow you to regulate security settings, for instance, network policies when different types of workloads are deployed in a separate namespace.

 

Advice-4: Separate sensitive workloads

A good practice is to avoid running workloads with sensitive data on a fanatical set of machines. Using this approach you reduce the risk of less secure applications to access the sensitive data when they are running on the same container executable environment or on the same host.
If we are having multiple cluster nodes and multiple pods are executed on the same node it gives more opportunity to the attacker.
We can do the separation using node pools (in the cloud or for on-premise) and we can also use Kubernetes tools like namespaces, taints, tolerations and others.

Advice-5: Access to the cloud service metadata needs to be protected.
The kubelet administrative credentials, sensitive metadata of the instance are often stolen or used with malicious intent to escalate privileges during a cluster.
The GKE metadata concealment function changes the mechanism for deploying the cluster in such a way that it avoids such a drag. And this method is strongly recommended until we come up with some permanent solution.

 

Advice-6: Create and define proper network policies for a cluster
This will allow you to control the access to the network in and out of the containerized application. To use this feature, you should have a network provider with the required access. We can manually enable this support in GKE(Google Kubernetes Engine). If you set up this properly, the first step you can take is to block the traffic from other namespaces.

 

Advice-7: Set the Pod Security Policy for the cluster

It helps you to set the default values that are required to start the cluster. You have to consider a defining policy and enabling the pod security policy for the admission controller. These steps are different for every cloud provider and the deployment model you used at the start.

For protecting yourself from spoofing attacks you need to disable the NET_RAW capability in containers.

 

Advice-8: Make your nodes more secure
For achieving the node security you can follow the following steps:

  • Ensure that the host is securely and correctly configured. One way is CIS Benchmarks; Many products have an auto checker that automatically checks the system for compliance with these standards.
  • Monitor the network availability of important ports. Ensure that the network is blocking access to the ports used by kubelet, including 10250 and 10255. Consider restricting access to the Kubernetes API server — with the exception of trusted networks. In clusters that did not require authentication and authorization in the kubelet API, attackers used access to such ports to launch cryptocurrency miners.
  • Minimize administrative access to Kubernetes hosts Access to cluster nodes should in principle be limited: for debugging and solving other problems, as a rule, you can do without direct access to the node.

 

Advice-9: Enable auto Logging
You should make sure that audit logs are enabled, and you are monitoring them regularly so that you can find out any unwanted behavior or API calls. Especially if you get something related to authorization failures. These entries have a forbidden message in front of them. These failures can be the signs that an attacker is trying to misuse the obtained credentials.

Managed solution providers (including GKE) provide access to this data in their interfaces and can help you set up notifications in case of authorization failures.

 

Now, we are aware of all the guidelines that need to be taken care of to make your Kubernetes cluster more secure. Even if your cluster is configured securely that doesn’t mean it's completely secured. You need to make it sure in other aspects of the configuration like operations of containers. Constantly monitoring can be proven advantageous.

 

 

Join TechCommanders Today. 

Over 60 Courses and Practice Questions! 

Coaching and CloudINterviewACE

Join TechCommanders

Stay connected with news and updates!

Join our mailing list to receive the latest news and updates from our team.
Don't worry, your information will not be shared.

We hate SPAM. We will never sell your information, for any reason.