Glossary

Kubernetes Network Policy

An application-centric construct in Kubernetes that specifies how pods are allowed to communicate with each other and other network endpoints, enforcing micro-segmentation for healthcare microservices.

Get in touch Learn more

Stylish WeWork-like workspace with hot desks and document wall, professional searching through enterprise knowledge base on a mounted ultrawide display, warm industrial pendants overhead.

MICRO-SEGMENTATION

What is Kubernetes Network Policy?

A Kubernetes Network Policy is an application-centric construct that defines how groups of pods are authorized to communicate with each other and other network endpoints, enforcing micro-segmentation for healthcare microservices.

A Kubernetes Network Policy is a specification that controls the flow of traffic at the IP address or port level (OSI layer 3 and 4) within a cluster. It defines a set of allowed ingress (inbound) and egress (outbound) rules for a selected group of pods, using podSelector and namespaceSelector labels to identify the source and destination entities. By default, pods are non-isolated and accept all traffic; applying a policy immediately restricts connectivity to only what is explicitly permitted, establishing a default-deny posture essential for protecting electronic Protected Health Information (ePHI).

In a HIPAA-compliant healthcare architecture, Network Policies are the primary mechanism for enforcing Zero Trust principles between microservices, such as isolating a FHIR Resource Mapping service from a Clinical De-identification Pipeline. The policies are enforced by the cluster's Container Network Interface (CNI) plugin, which must support the NetworkPolicy API. This allows DevOps engineers to codify segmentation rules as Policy as Code, ensuring that a compromised data extraction pod cannot laterally access the Protected Health Information (PHI) stored in a separate database service, thereby satisfying the technical safeguards required under the HIPAA Security Rule.

MICRO-SEGMENTATION FOR HEALTHCARE

Key Features of Kubernetes Network Policies

Kubernetes Network Policies enforce zero-trust communication rules between pods, ensuring that healthcare microservices handling ePHI remain isolated from unauthorized access.

Pod-Level Micro-Segmentation

Network Policies operate at the pod level, not the host or IP level. This allows precise control over which microservices can communicate, enforcing the principle of least privilege. For example, a PHI-processing pod can be restricted to only accept ingress traffic from a specific FHIR API gateway pod on port 443, blocking all lateral movement from compromised services.

Pod-Level

Granularity

Namespace Isolation

Policies can isolate entire namespaces to create logical security boundaries between environments. A common healthcare pattern denies all ingress from other namespaces by default, then explicitly allows traffic only from an ingress controller namespace. This prevents a development pod from accidentally accessing production ePHI data stores.

Label-Based Selectors

Network Policies use Kubernetes labels to dynamically select pods and namespaces. This decouples security rules from ephemeral IP addresses. Key selector types:

podSelector: Targets specific application tiers (e.g., app: fhir-server)
namespaceSelector: Targets entire environments (e.g., environment: production)
ipBlock: Whitelists external CIDR ranges for egress to on-premise systems

Ingress and Egress Control

Policies independently govern ingress (inbound) and egress (outbound) traffic. A healthcare AI model pod can be configured to:

Ingress: Accept inference requests only from the clinical API gateway
Egress: Connect only to the encrypted PHI database and a specific model registry endpoint This bidirectional control prevents data exfiltration even if the pod is compromised.

Default Deny Posture

A foundational zero-trust pattern is the default deny-all policy. By applying a policy that denies all ingress and egress traffic to a namespace, you create a whitelist-only environment. Every allowed connection must then be explicitly defined, ensuring no implicit trust exists between services. This is a critical HIPAA technical safeguard for ePHI environments.

CNI Plugin Enforcement

Network Policies are enforced by the Container Network Interface (CNI) plugin, not by kube-proxy. To use policies, the cluster must have a compatible CNI like Calico, Cilium, or Weave Net. Cilium, for example, uses eBPF to enforce policies at the kernel level, providing deep observability and high-performance filtering for healthcare workloads.

KUBERNETES NETWORK POLICY

Frequently Asked Questions

Essential questions and answers about implementing Kubernetes Network Policies to enforce micro-segmentation and zero-trust networking for HIPAA-compliant healthcare workloads.

A Kubernetes Network Policy is an application-centric construct that defines how groups of pods are authorized to communicate with each other and other network endpoints. It operates as a firewall rule at the pod level, specifying ingress (inbound) and egress (outbound) traffic rules using label selectors to identify pods, namespaces, and IP blocks. The policy is enforced by the cluster's Container Network Interface (CNI) plugin, such as Calico, Cilium, or Weave Net, which must support NetworkPolicy enforcement. By default, Kubernetes allows all pod-to-pod traffic; a NetworkPolicy explicitly whitelists permitted connections, implementing a zero-trust networking model where only explicitly allowed traffic flows. For healthcare microservices processing Protected Health Information (PHI), this ensures that a clinical data extraction service can only communicate with the FHIR mapping service and the audit log, not with any other pod in the cluster.

Enabling Efficiency, Speed & Accuracy

Intelligent Analysis, Decision & Execution

We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.

Talk to Us

Search across company data

Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.

Useful when people spend too long searching or get different answers from different systems.

Enterprise searchRAGPermissions

Automate internal workflows

Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.

Useful when repetitive work moves across multiple tools and teams.

AI agentsWorkflow automationGovernance

Add AI to products and internal tools

Build assistants, guided actions, or decision support into the software your team or customers already use.

Useful when AI needs to be part of the product, not a separate tool.

AI integrationDecision supportModel routing

NETWORK POLICY ECOSYSTEM

Related Terms

Core concepts for implementing micro-segmentation and zero-trust networking in HIPAA-compliant Kubernetes clusters.

Pod Selector

The primary mechanism for associating a Kubernetes Network Policy with a target workload. A podSelector uses label-based matching to identify the group of pods to which the ingress or egress rules apply.

An empty podSelector ({}) selects all pods in the namespace.
Combined with namespaceSelector, it enables cross-namespace policy enforcement.
This is the foundation of identity-based micro-segmentation, decoupling security policy from ephemeral IP addresses.

EXPLORE

Ingress vs. Egress Rules

Network Policies define traffic directionality through two distinct rule sets:

Ingress: Controls inbound traffic to the selected pods. Specifies allowed sources (from) and permitted ports (ports).
Egress: Controls outbound traffic from the selected pods. Specifies allowed destinations (to) and permitted ports.

A policy with only ingress rules implicitly allows all egress, and vice versa. For a true default-deny posture, separate policies must explicitly deny both directions.

CNI Plugin Requirement

Kubernetes Network Policy objects are merely API resources; they require a Container Network Interface (CNI) plugin that supports policy enforcement to actually implement the rules.

Calico, Cilium, and Weave Net are common CNIs with full policy support.
Without a compatible CNI, policies are created but never enforced, leaving pods wide open.
Cilium leverages eBPF for kernel-level enforcement, offering fine-grained observability and identity-based security ideal for healthcare workloads.

Default Deny Policy

A foundational security pattern that blocks all traffic to and from pods in a namespace until explicit allow rules are defined.

Achieved by creating a Network Policy with an empty podSelector ({}) and no ingress/egress rules.
This enforces the principle of least privilege at the network layer.
In a HIPAA context, a default-deny posture ensures that a newly deployed microservice handling ePHI cannot communicate with any other service until a specific, auditable policy is applied.

Namespace Selector

Extends policy scope beyond the local namespace by allowing or denying traffic from pods in other namespaces based on their Kubernetes labels.

namespaceSelector matches entire namespaces by label.
Combined with podSelector, it enables precise cross-namespace rules (e.g., allow the billing service in the finance namespace to reach the claims pod in the clinical namespace).
This is critical for segmenting multi-tenant healthcare platforms where payer and provider services coexist on a shared cluster.

IPBlock Selector

Defines traffic rules based on CIDR ranges rather than Kubernetes labels, useful for controlling communication with external resources outside the cluster.

ipBlock specifies allowed or denied IP ranges with optional except exclusions.
Commonly used to restrict egress to only approved external APIs, such as a FHIR server endpoint or a pharmacy benefit manager gateway.
Combining ipBlock with pod and namespace selectors within a single rule creates a logical AND condition, tightening security posture.

About the author

Prasad Kumkar

CEO & MD, Inference Systems

Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.

His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.

Limited slotsGet a Free AI Consultation

How We Work

Custom AI workflows for your Business

One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.