5 NetworkPolicy Mistakes That Leave Kubernetes Clusters Completely Unprotected
Kubernetes NetworkPolicy objects can exist in the API without actually restricting any traffic, creating a false sense of security that only surfaces during penetration tests. The original Russian article from OTUS details five critical mistakes that produce exactly this outcome: policies are visible via kubectl get networkpolicy yet traffic flows freely.
CNI Plugin Does Not Support NetworkPolicy
Kubernetes stores NetworkPolicy objects but relies on the Container Network Interface plugin for enforcement. Plugins such as Calico, Cilium, and Weave Net implement them, while plain Flannel and kubenet do not. Administrators can confirm the plugin by checking pods in the kube-system namespace, yet the most reliable test applies a deny-all policy in a test namespace and attempts cross-namespace connectivity with tools like nicolaka/netshoot.
Default-Deny Egress Blocks DNS Resolution
Applying an egress deny-all rule immediately breaks name resolution because queries to CoreDNS on port 53 are also blocked. Applications report UnknownHostException or timeouts rather than access denied errors, leading teams to investigate the DNS service instead of the policy. The recommended fix adds a separate policy allowing UDP and TCP traffic to the kube-dns pods in the kube-system namespace.
Single Dash Creates Cluster-Wide Access
A misplaced dash in the YAML turns an AND condition into an OR condition. The correct structure places namespaceSelector and podSelector under the same list item so that only pods matching both labels are permitted. When separated by an extra dash, any pod bearing the label app: api from any namespace gains access, silently expanding the attack surface.
namespaceSelector Matches Labels, Not Namespace Names
The selector matchLabels: name: monitoring looks for a label on the namespace object, not its name. Most namespaces only carry the automatic label kubernetes.io/metadata.name. Administrators must either use this built-in label or manually apply custom labels, understanding that custom labels can be forgotten on newly created namespaces.
Confusion Between Protected Pods and Allowed Sources
The top-level podSelector defines which pods the policy protects, while selectors inside from or to blocks define allowed peers. Swapping these produces a policy with an empty from: [] list that permits traffic from everywhere. An empty ingress list without any rules denies all ingress, whereas a rule containing an empty source list allows all sources.
Additional coverage gaps remain even with correct policies: pods using hostNetwork: true bypass the CNI, intra-pod localhost traffic between containers is uncontrolled, and response traffic for established connections is automatically permitted. The article advises starting with traffic tests, rolling out default-deny together with DNS allowances, using policy audit modes in Calico and Cilium, and keeping a single-command rollback ready.
Related articles
Ghost Assets in Vulnerability Management: How Identification, Merging and Asset History Eliminate Anomalies in MaxPatrol VM
Positive Technologies experts explain how infrastructure changes create duplicate, merged and phantom assets that distort vulnerability management. The article details three core mechanisms inside MaxPatrol VM: unique asset identification across scan sources, non-destructive merging of new and existing data, and full lifecycle history with configurable aging policies. It describes how the system distinguishes assets using prioritized keys such as system ID, FQDN, MAC address and VM ID, then applies recursive merging rules that respect multiple data sources. Policies allow teams to set freshness and obsolescence thresholds, automatically hiding assets after 90 days while preserving historical snapshots for PDQL queries. The piece also covers practical cloning and partial-scan scenarios that can produce misleading duplicates or lingering collections.
GreyNoise Detects Active Exploitation Attempts of CVE-2021-36260 Against Hikvision Cameras
GreyNoise recorded exploitation attempts targeting CVE-2021-36260 in Hikvision cameras and recorders between September 21 and October 1. The vulnerability carries a CVSS score of 9.8 and allows unauthenticated remote command execution through insufficient input validation in the embedded web server. Attack traffic originated from four IP addresses, three routed through a commercial VPN in Lithuania and one from a Ukrainian residential network, with all targets located in Ukraine. Attackers leveraged a publicly available Nuclei template to probe devices, though GreyNoise confirmed only scanning activity and not successful compromises. The five-year-old flaw remains actively scanned despite an available firmware patch from Hikvision and a CISA advisory recommending immediate updates. Password changes provide no protection because the attack requires no authentication. Defenders are advised to apply firmware updates, remove devices from public internet exposure, and segment video surveillance networks from critical infrastructure.
Splunk Enterprise Discloses 46 Vulnerabilities Including Critical Patroni Authentication Flaw
Splunk has published three security advisories detailing a total of 46 vulnerabilities affecting Splunk Enterprise and related components. Three of the issues were rated critical, with CVE-2026-76268 receiving a CVSS v3.1 base score of 9.8. The flaw resides in the Patroni REST API used for PostgreSQL cluster management within search head clusters, allowing unauthenticated remote attackers to execute arbitrary operating system commands. Another high-severity issue, CVE-2026-76266, enables local privilege escalation to root on Linux systems during package updates. The remaining vulnerabilities cover product code, internally identified problems, and third-party packages. Organizations are urged to apply the available patches promptly.
Smart Fish Tank Power Strip Server Breached, Killing Aquarium Fish During National Day Holiday
During China's National Day holiday, the cloud servers of Woda Technology's smart power strips for fish tanks were compromised by malicious hackers, causing widespread remote disconnections and power outages for user devices. The attack left heating rods, oxygen pumps, and circulation systems offline for hours, resulting in the deaths of koi, arowana, and other ornamental fish that users had maintained for years. Woda issued a public notice confirming the intrusion was not a product defect or user error but a deliberate network attack, and the company has since upgraded firewalls, added multi-layer cloud protections, deployed backup servers, and improved local offline logic to prevent future failures. The incident highlights a critical IoT design flaw where devices rely entirely on vendor cloud platforms for control, allowing attackers who breach the server to remotely manage household appliances at scale. Security experts note that the same architecture is used across smart speakers, locks, cameras, and other consumer devices, creating a broad attack surface with minimal updates or segmentation. Woda has reported the case to authorities and preserved logs for forensic investigation.