Kubernetes' market share continues to grow as organizations increase their use of containerized software and adopt cloud architectures. According to a Cloud Native Computing Foundation (CNCF) survey, Kubernetes use rose from 58% in 2018 to 91% in 2020. 

However, along with rapid growth, Kubernetes has already experienced a fair share of cyberattacks, with six major ones last year alone (CVE-2020-14386, CVE-2020-2121, CVE-2020-8558, CVE-2020-8559, CVE-2020-10749, and CVE-2020-8557). This trend will most likely continue or even accelerate. As more Kubernetes clusters are put into production, bad actors will be motivated to find more security holes.

Kubernetes containers often have loose security settings, sometimes by default, that hackers can leverage to execute a cyberattack. Lightspin inspected where our clients use "privilege" mode, which provides almost unrestricted access to resources on the host system; "privilege escalations," where processes are given expanded privileges; and "run as root," which allows unrestricted container management. Three-quarters of the companies surveyed matched one or more of the issues, and the average percentage of pods affected was nearly 25%. These permissions are often used for development purposes but present an unacceptable level of risk when containers are put into production.

Why Kubernetes Is an Easy Target
Some increases in attacks targeting Kubernetes are due to new trends in development environments. With the move to break systems down into smaller functions, many IT teams are developing microservices that each require authentication and access control and thereby open a new attack surface. Microservices tend to be highly volatile, with the ability to move and pop in and out, making it hard to defend all their respective entry points from hackers.

Cloud environments are becoming more complex, consisting of thousands of cloud assets from multiple vendors. Often, there is confusion about the borders of security between internal organizations and cloud vendors. Gartner research indicates that about 95% of cloud security breaches through 2022 will come from customer errors fueled by misconfigurations, myths, and misunderstandings. According to our internal research, it can take 270 days on average for organizations to even notice they have a misconfiguration issue gumming up their security. That gives hackers plenty of time to access systems and files and collect proprietary and confidential data.

Kubernetes ecosystems are often constructed from various third-party open source components, making it difficult to enforce standard implementations that include proper configurations and security authorizations. This lack of control is aggravated by an emphasis on speeding product delivery. DevOps deployments often race ahead of security, introducing new functions or services that are unprotected and increasing the attack surface.

Guidelines to Protect Against Vulnerabilities
Kubernetes comes with security controls that need to be customized for each organization and its risks. Since the programming environment is highly volatile, the process needs to be updated constantly. Here are some general guidelines to consider:

• As Kubernetes is entirely API-driven, controlling and limiting who can access the cluster and what actions they are allowed to perform is the first line of defense. Make sure you lock down access to the Kubernetes API server by ensuring that the API server is accessible only from trusted subnets that utilize the appropriate firewall rules. The ideal scenario is to expose the server to a virtual private cloud (VPC) network instead of the open Internet. 
  
  
• One of the most difficult challenges security teams face is the lack of full visibility into Kubernetes architectures. Your team needs to identify and nail down all the ports that connect to your hosts, containers, and virtual machines, just like you would do for any physical, on-site data resource. Look out for all the assets with undefined security profiles or loose default settings. Be aware that the Kubernetes default is that every pod can speak to all other pods with no security restrictions. One rule of thumb is to grant the lowest level of operating system privilege necessary while constructing containers. Ensure that anonymous authentication is disabled. 
  
  
• Allow each microservice access to only the resources it needs. This way, a vulnerability in one microservice will not expose the rest of your system to an attacker. Make sure you inspect the authorized users for each storage asset. 
  
  
• Investigate using a tool that will give you a visual map of a Kubernetes cluster that includes role-based access control (RBAC), networking, and configuration layers down to the microservice level. Seeing the relationship between all the components or the context of each vulnerability will put security incidents into perspective to prioritize alerts and take immediate action when needed. 

The best strategy is to focus on the attack paths that threaten the most vulnerable and valuable assets. Security systems that monitor traffic for anomalies can create an excessive number of alerts that take up valuable time. But by focusing on the assets you want to protect and protecting the cloud from the inside out, you can home in on the most urgent threats.

The race to innovate faster in our online digital economy is creating more attack surfaces that introduce a higher risk of data breaches. Having full visibility into all Kubernetes components, minimizing access to assets, and focusing on the attack path can secure environments while making the best use of security personnel. Understanding each threat's context is the best way to assess priorities and take action to protect sensitive data and prevent data breaches.