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
COVID-19: Latest Security News & Commentary
Dark Reading Staff 10/23/2020
7 Tips for Choosing Security Metrics That Matter
Ericka Chickowski, Contributing Writer,  10/19/2020
Russian Military Officers Unmasked, Indicted for High-Profile Cyberattack Campaigns
Kelly Jackson Higgins, Executive Editor at Dark Reading,  10/19/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-10-23
A Cross-Site Request Forgery (CSRF) vulnerability is identified in FruityWifi through 2.4. Due to a lack of CSRF protection in page_config_adv.php, an unauthenticated attacker can lure the victim to visit his website by social engineering or another attack vector. Due to this issue, an unauthenticat...
PUBLISHED: 2020-10-23
FruityWifi through 2.4 has an unsafe Sudo configuration [(ALL : ALL) NOPASSWD: ALL]. This allows an attacker to perform a system-level (root) local privilege escalation, allowing an attacker to gain complete persistent access to the local system.
PUBLISHED: 2020-10-23
NVIDIA GeForce Experience, all versions prior to, contains a vulnerability in the ShadowPlay component which may lead to local privilege escalation, code execution, denial of service or information disclosure.
PUBLISHED: 2020-10-23
An arbitrary command execution vulnerability exists in the fopen() function of file writes of UCMS v1.4.8, where an attacker can gain access to the server.
PUBLISHED: 2020-10-23
NVIDIA GeForce Experience, all versions prior to, contains a vulnerability in NVIDIA Web Helper NodeJS Web Server in which an uncontrolled search path is used to load a node module, which may lead to code execution, denial of service, escalation of privileges, and information disclosure.