@muhammadali642 ・ Feb 14,2022 ・ 7 min read ・ 759 views ・ Originally posted on www.w6d.io
Kubernetes security is critical throughout the life of the container due to the dynamic and distributed nature of a cluster. For a cluster to be considered effective and stable, it needs to be secure from unauthorized changes. We’ll discuss the different kubernetes security practices that will secure your cluster and increase control of the cluster’s resources.
This feature has been available since Kubernetes 1.6. The RBAC plays an important role in managing Kubernetes resources by controlling the authorization feature. One of the biggest benefits of this feature is the ability to adjust permissions without having to restart the whole cluster. After you enable it, you’ll be able to give the necessary permissions to the system’s components. Users can only allow full access to components when it is completely necessary for a specific situation.
The etcd is the brain of the cluster because it keeps a record of everything happening in the cluster. If a hacker gained access to it, they would be able to view all the cluster operation details. It is very important to keep it safe and limit access to only the authorized people with the right credentials. It should be protected to keep the sensitive cluster information a secret.
There are two ways to protect the etcd:
Being one of the most used services to access the system remotely, it is an attractive point of entry for hackers. This is why restricting access to it is very important if you want to keep the cluster secure. SSH’s two user restriction attributes, allow and deny, are enough to manage its security needs. One of the ways to secure it is by denying access to port 22 on the nodes and only allowing access to it when debugging. Even when you allow it, only given access via the organization’s VPN or bastion host. These security settings can be configured through your cloud provider.
You should place the nodes are on a separate network that is not exposed to the public network directly. This adds an extra layer of security where traffic to and from the node can be controlled. Also, avoid exposing the nodes to the corporate network so as not to mess with the security mesh’s integrity. To achieve this, you have to ensure that traffic and Kubernetes control are both isolated. Failure to isolate them will lead to both flowing on the same pipe, thereby opening access to the data plane. It is recommended that you perform the configurations using the ingress controller to comprehensively implement the isolation. With an ingress controller, you limit the master node connection to only the network access control list specified port.
Running containers in the pods as a root user is a common mistake that can lead to an involuntary configuration change. In Kubernetes, the user id is mapped onto the host of the container, meaning that the user also appears as a root on the nodes that it runs on. Although there is a Kubernetes mechanism that stops the change in privileges using this strategy, the security vulnerability that can be exploited by an experienced hacker still exist. The way to prevent running container as root is to create a user with a known id by modifying inbuilt containers’ Dockerfile.
One of the most used images to run apps in Docker containers is Ubuntu, while the size of the image is not ideal to run it in a Kubernetes cluster, the image contains the OS package manager (APT) and gives users access to shell. The problem is that both features (package manager and shell) present security risks and may contain vulnerabilities.
If installing packages is necessary, the best practice in this case is removing the package manager after using it.
According to an OWASP guide: “Restricting what’s in your runtime container to precisely what’s necessary for your app is a best practice employed by Google and other tech giants that have used containers in production for many years. It improves the signal to noise of scanners (e.g. CVE) and reduces the burden of establishing provenance to just what you need.”
Ensure that you are always running the latest Kubernetes version available. This will ensure that you always have the latest security solutions available. The Kubernetes community is always creating new patches to increase the system’s security and these updates are regularly published.
Namespaces help in organizing a cluster into virtual sub-clusters and this gives you more control of the cluster. This is very important when the cluster is acting as a multi-tenant environment.
Namespaces can add restrictions in two ways:
The audit log keeps a record of all suspicious API calls and automatically flags them. For instance, an authentication failure is flagged because it could be a sign that an attacker is trying to gain access to the cluster using stolen credentials. Over time you can be able to view the cluster’s health and stability based on the number of suspicious calls revoked.
There are four logging options that are available:
If an attacker gains access to a Kubelet, they can compromise the entire cluster. Here are some of the configuration options that can be utilized in securing the Kubelet from attacks:
Avoid storing the application’s sensitive details in the configmap and instead store them in secret. The difference between the two is that while Secret stores its data in base64 format, configmap stores in plain text. Encrypting details such as username, database name and passwords adds another layer of security to containerized applications.
OWASP also provides a framework that can be used to evaluate applications’ security. This comes in handy when a company wants to conduct an audit of its applications. You can use OWASP’s top 10 security risks to decide the risks that will require a higher priority.
The OWASP foundation maintains the The OWASP Cheat Sheet Series repose which was created to provide a concise collection of high value information on specific application security topics. This cheat sheet includes a Kubernetes related part and contains almost everything you need to know in order to secure your Kubernetes clusters and Docker containers.
WildCard CI/CD solution takes a security-first approach in handling development, delivery, and deployment. Try it here for free!
Wildcard is a NoCode platform that provides a solution to help organizations, and developers, even those without DevOps experience or coding knowledge, to successfully implement and manage versioned infrastructure using NoCode CI/CD pipelines. It enables collaboration, auditing, and automation. You can use Wildcard to build, deploy, and manage applications without writing a single line of code. Start for free by singing using Github or GitLab.
Join other developers and claim your FAUN account now!
Only registered users can post comments. Please, login or signup.