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.

Cloud

3/24/2020
02:00 PM
Gadi Naor
Gadi Naor
Commentary
50%
50%

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
Comments
Oldest First  |  Newest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 5/28/2020
GDPR Enforcement Loosens Amid Pandemic
Seth Rosenblatt, Contributing Writer,  5/27/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Can you smell me now?
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-11018
PUBLISHED: 2020-05-29
In FreeRDP less than or equal to 2.0.0, a possible resource exhaustion vulnerability can be performed. Malicious clients could trigger out of bound reads causing memory allocation with random size. This has been fixed in 2.1.0.
CVE-2020-13634
PUBLISHED: 2020-05-29
In Windows Master (aka Windows Optimization Master) 7.99.13.604, the driver file (WoptiHWDetect.SYS) allows local users to cause a denial of service (BSOD) or possibly have unspecified other impact because of not validating input values from IOCtl 0xF1002558
CVE-2020-12675
PUBLISHED: 2020-05-29
The mappress-google-maps-for-wordpress plugin before 2.54.6 for WordPress does not correctly implement capability checks for AJAX functions related to creation/retrieval/deletion of PHP template files, leading to Remote Code Execution. NOTE: this issue exists because of an incomplete fix for CVE-202...
CVE-2020-11017
PUBLISHED: 2020-05-29
In FreeRDP less than or equal to 2.0.0, by providing manipulated input a malicious client can create a double free condition and crash the server. This is fixed in version 2.1.0.
CVE-2020-4306
PUBLISHED: 2020-05-29
IBM Planning Analytics Local 2.0.0 through 2.0.9 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 17...