Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


02:00 PM
Gadi Naor
Gadi Naor

How to Secure Your Kubernetes Deployments

As more companies shift their software to a microservices-based architecture and orchestrate their containerized applications in Kubernetes, distributed security controls become a must.

At a time when almost every company is to some degree a software company, digital transformation and cloud adoption are not just strategic but critical to enterprise success. Whether companies were born into the cloud or are just setting foot into it, it's important to know that the traditional security practices of firewall-based network segmentation are no longer dependable in this new frontier.

Indeed, the effectiveness of traditional firewalls is fundamentally minimized by the scale and elasticity of cloud infrastructure, virtual private cloud networks, and cloud-native applications, and the many stakeholders that build, ship, and operate those applications. As more companies shift their software to a microservices-based architecture and orchestrate their containerized applications in Kubernetes, distributed security controls become a must.

In cloud environments, and in Kubernetes specifically, the threat and risk model should account for internal-born threats already present inside one of the running components. Examples include a rogue software library imported for use or a container image coming from an untrusted source.

Kubernetes has solid native security controls compared to open-platform native techrnologies or even proprietary virtual machine-based platforms. Kubernetes offers flexible authentication machinery, mature role-based access control (RBAC) for authorization, fine-grained controls on how processes run, validation of resources before admitting them into a Kubernetes cluster, and adaptive pod (colocated containers) east-west network segmentation.

Implementing fine-grained microservices network segmentation has a high impact as far as reducing and limiting the attack surface, limiting the ability to pivot from one component to another, exfiltration of data, and other forms of lateral movements.

Microsegmentation Management
Undeniably, one of the biggest challenges with microsegmentation is managing it over time. As of Kubernetes v1.8, the following native network policy APIs are generally available:

• By default, Kubernetes workloads (pods) are not isolated; pods accept traffic from any source, and pods are allowed to send traffic to any destination.

• Kubernetes network policy semantics only enable east-west (cluster internal) segmentation, as well as specifying Classless Inter-Domain Routing (CIDR) blocks. It does not support domain names (or domain wildcards) in the policy syntax.

• Kubernetes NetworkPolicy captures application intent by specifying how groups of pods are allowed to communicate with each other and other network endpoints (CIDR).

• Kubernetes NetworkPolicy resources use labels to select pods and define rules that specify what traffic is allowed to the selected pods.

• The Kubernetes Container Network Interface (CNI) plugin must support the network-policy APIs in order to enable network policy enforcement. Some popular plugin choices include Calico and Flannel, as well as the cloud provider CNI plugin that leverages the cloud service provider virtual private cloud (VPC) networking. All of the recommended plugins can be found in the Kubernetes documentation.

Right off the bat, one simple policy you can set to flip the open-by-default paradigm and close your pods off to traffic is the deny-all policy, also known as blacklisting. Blacklisting a pod denies all traffic to and from other pods. The best practice is to blacklist all of your pods, then set additional network policies to explicitly allow communication between pods as needed, also known as whitelisting. You can do this with a default deny-all policy, which changes the namespace’s default to deny all non-whitelisted traffic.

Additional network security configurations that control which traffic sources (network blocks) are allowed to be ingested into the cluster by load balancers and layer-7 proxy (Kubernetes Ingress) are available in the form of special resource annotations. This configuration comes in the form of special tags that are consumed by a Kubernetes cloud controller, a glue layer between Kubernetes, and the underlying platform the cluster runs on. The cloud controller programs the underlying VPC networking security configuration as well as load balancers in accordance with those special annotations.

Not Far Enough
While this seems a healthy amount of network security controls, Kubernetes' native controls are not sufficient:

• Workloads (pods) that run on the host network are not subject to whatever network policies were configured on the host network.

• Kubernetes policies are additive and adhere to a whitelisting approach. It lacks very basic semantics of drop-actions in network policy rules. Whitelisting extensions can be achieved with third-party tools and open source projects such as Calico.

• Workloads that require access to resources outside the cluster are denoted by domain endpoints (such as database or SaaS services like Slack) that can't be segmented on their egress paths.

• Identity-based access controls are not addressed by the Kubernetes native controls and require side-car based proxies to establish such controls.

• Kubernetes infrastructure does not expose policy violation statistics or logs, which means the substance that intrusion detection and prevention systems rely on is absent.

• The domain name system (DNS), Kubernetes' underlying service discovery, is open by default for every pod in the cluster. This means exfiltration methods such as DNS tunneling and abusing inherent weaknesses in DNS protocol require specialized network security analysis to detect anomalies and threats.

Take Control of Your Own (Security) Fate
Kubernetes is still relatively new and can have a steep learning curve. Ultimately, understanding that Kubernetes is open by default is the most important step you can take toward securing your cloud-native applications and preventing unwanted traffic. With this understanding, you can change the default and take control of the traffic flowing through your application.

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's featured story: "Three Ways Your BEC Defense Is Failing & How to Do Better."

Gadi Naor has 18 years of engineering experience, from kernel-based development through leading development of cybersecurity products. He started his professional career at Check Point. Gadi then joined Altor Networks, a pioneer in virtualized data center security, later ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
When It Comes To Security Tools, More Isn't More
Lamont Orange, Chief Information Security Officer at Netskope,  1/11/2021
US Capitol Attack a Wake-up Call for the Integration of Physical & IT Security
Seth Rosenblatt, Contributing Writer,  1/11/2021
IoT Vendor Ubiquiti Suffers Data Breach
Dark Reading Staff 1/11/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
2020: The Year in Security
Download this Tech Digest for a look at the biggest security stories that - so far - have shaped a very strange and stressful year.
Flash Poll
Assessing Cybersecurity Risk in Today's Enterprises
Assessing Cybersecurity Risk in Today's Enterprises
COVID-19 has created a new IT paradigm in the enterprise -- and a new level of cybersecurity risk. This report offers a look at how enterprises are assessing and managing cyber-risk under the new normal.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-01-15
An issue was discovered in Malwarebytes before 4.0 on macOS. A malicious application was able to perform a privileged action within the Malwarebytes launch daemon. The privileged service improperly validated XPC connections by relying on the PID instead of the audit token. An attacker can construct ...
PUBLISHED: 2021-01-15
Docker Desktop Community before on macOS mishandles certificate checking, leading to local privilege escalation.
PUBLISHED: 2021-01-15
OneDev is an all-in-one devops platform. In OneDev before version 4.0.3, there is a critical vulnerability which can lead to pre-auth remote code execution. AttachmentUploadServlet deserializes untrusted data from the `Attachment-Support` header. This Servlet does not enforce any authentication or a...
PUBLISHED: 2021-01-15
OneDev is an all-in-one devops platform. In OneDev before version 4.0.3, AttachmentUploadServlet also saves user controlled data (`request.getInputStream()`) to a user specified location (`request.getHeader("File-Name")`). This issue may lead to arbitrary file upload which can be used to u...
PUBLISHED: 2021-01-15
OneDev is an all-in-one devops platform. In OneDev before version 4.0.3, the REST UserResource endpoint performs a security check to make sure that only administrators can list user details. However for the `/users/` endpoint there are no security checks enforced so it is possible to retrieve ar...