Balance innovation and agility with security and compliance
risks using a 3-step process across all cloud infrastructure.
Step up business agility without compromising
security or compliance
Everything you need to become a Kubernetes expert.
Always for free!
Everything you need to know about Magalix
culture and much more
As organizations are adopting microservices-based architecture for their application or software development, many are also adopting Kubernetes for container orchestration. Kubernetes simplifies cloud-native infrastructure where a few lines of code and one Kubernetes command can deliver services, replication, load balancing, auto-scaling and you are ready to serve your users on the Internet. However, Kubernetes also introduces some blind spots within the configuration that can lead to disaster. These blind spots can be referred to as Kubernetes Misconfigurations.
According to a survey conducted by Red Hat, 60% of respondents out of 500 DevOps, engineering, and security professionals noted that there was a Kubernetes Misconfigurations incident in their environments over the last 12 months, 47% are still worried about exposures due to Kubernetes Misconfigurations in their container and Kubernetes environments. You can have a look at the report here to know about the survey in detail.
Hence, it is always better to identify Kubernetes Misconfigurations before the workload is deployed to Production. In this article, we will try to understand 6 Common Kubernetes Configurations Mistakes that need to be avoided to save ourselves from the potential disaster, security risk, data breach in the Kubernetes Cluster.
Running containers with the same privileges as that of the host can be very dangerous. Running containers in privileged mode gives root access to the processes in the privileged containers on the host. This is false by default; however, if it is set to true and if an attacker breaches the container then that can be like a nightmare. This privileged container then can be used by an attacker as an entry point for attacks and to spread malware, malicious code to compromised hosts and networks.
To avoid such a situation, you are advised not to set “securityContext privileged to true”. Have a look here to know how Magalix can help you with this.
apiVersion: v1 kind: Pod metadata: name: spec: containers: - name: image: securityContext: privileged: true # ← ← (This must not be true)
We can specify requests and limits in containers for resources like CPU and RAM so that the running containers are not allowed to use more than the limit that has been set. If we do not specify the limits, then the containers in the pods running on nodes with enough resources can consume more than what has been requested. This can slow down other services or can lead to OOM (Out Of Memory) events which in turn can take down other Pods running on the node that eventually can bring down your application.
To make sure that your workload consumes resources as per your requirement, it is important to specify resource requests and limits to containers in your pods. Click here to know Kubernetes resource requests and resource limits and here to enforce ResourceQuotas on Namespaces.
apiVersion: v1 kind: Pod metadata: name: spec: containers: - name: image: Resources: Requests: # ← ← memory: "64Mi" cpu: "250m" Limits: # ← ← memory: "128Mi" cpu: "500m"
Kubernetes Cluster comes out of the box with a default namespace called “default”. It means, if we do not specify any namespace to resources we create, then the resources are created in the “default” namespace. In such a case, resources like pods may result in accidental disruption with other services.
Using the “default” namespace can be the most common Kubernetes Misconfigurations. Doing so can make it difficult to apply security controls such as Network Policies, restrict access to resources within the cluster, or create user accounts that have access to only particular resources.
When you run multiple applications or different environments for your applications in the same Kubernetes Cluster, it is better to use different namespaces for security or resource allocation reasons. In this way, you can also assign namespace-specific permissions instead of cluster-wide permissions while using RBAC.
apiVersion: v1 kind: Namespace metadata: name: # ← ←
apiVersion: v1 kind: Pod metadata: name: namespace: test # ← ← spec: containers: - name:
Whenever you create a docker image for your application, you use a base or parent image for it. Containers are built on top of the base image being used to create them. You need to be very cautious while choosing the base image as these images could contain vulnerabilities.
Operation "Red Kangaroo", Dynamic Analysis of 4M Public Docker Container Images, by Prevasio, revealed:
You can have a look at the summary here.
To make sure you do not become a victim of such images containing vulnerabilities that could be a threat to your applications, it is always recommended to start with enforcing image provenance policies and vulnerability scanning practices. To help yourself, you can have a look at the Magalix platform that offers all this and more.
Imagine you have all your workload on Kubernetes Clusters and you are carrying out a maintenance activity to upgrade the Cluster. While doing so, you took down one of your nodes running your pods which in turn killed your pods. This can lead to service unavailability or service outages due to draining nodes.
You are advised to create a PodDisruptionBudget (PDB) for each application to run highly available applications even when you introduce frequent voluntary disruptions. By creating a PodDisruptionBudget you make sure that no matter what the Cluster Administrator does to nodes as part of the maintenance activity i.e. if there are any voluntary disruptions., there should always be a minimum number of pods running in the cluster.
apiVersion: policy/v1 kind: PodDisruptionBudget # ← ← (Protecting an Application with a PodDisruptionBudget) metadata: name: spec: minAvailable: selector: matchLabels: :
Applications deployed on Kubernetes can be accessed via Services. A Service is a Kubernetes object that exposes the application. It is an abstraction layer that defines a logical set of Pods. Requests from a Service are forwarded to backend Pods.
All the micro-services usually do not require access to them from the external network. While these applications are exposed via services, it may happen that the services are exposed to the external world, and external requests can reach pods via these services that can give away access to sensitive data.
It is important that you not expose your production workloads to outside networks or to the Internet using the Node Port and Load Balancer. You should always forbid the use of these two settings unless required.
NodePort / Load Balancer
apiVersion: v1 kind: Service metadata: name: spec: type: NodePort OR LoadBalancer # ← ← (Service available externally)
In this article, we saw 6 common Kubernetes Configurations that need to be avoided to save ourselves from the potential disaster of our Infrastructure. These are just a few Common Kubernetes Configurations, there are a lot of other configuration options Kubernetes brings up that need to be checked, monitored, and corrective action must be taken if required.
If we have to do this manually across the infrastructure then this would be very cumbersome. To keep the infrastructure and applications tightly secured, we do not have to look after all the moving parts in the cluster, rather, a tool like Magalix can come to the rescue here.
Magalix is a platform that helps us to enforce best practices, security, and standards inside Kubernetes and cloud-native apps and gives the right visibility at the right time to your team. Magalix scans and generates detailed compliance reports of our Kubernetes cluster, it helps protect our clusters against violations to keep them Secure, Compliant, and Reliable, and also exports events from the cluster to many different tools and formats. To know more about the platform, you are welcome to register with Magalix to get started with your free account today.
Learn how to improve cloud-native security with CIS Benchmarks for K8s. See how Magalix can help you reinforce security with its new CIS Benchmarks Policy Pack.
Find out how to avoid misconfigurations in Kubernetes that may lead to security breaches or sensitive data leaks.