Current Architecture Overview

In our on-premise environment, we have a Kubernetes (K8s) infrastructure where multiple microservices are deployed. Since the LoadBalancer service type is not supported in our on-premise setup, we utilize the NodePort service type to expose the microservices externally. The NodePort services open specific ports on all the nodes in the cluster, allowing external traffic to access the microservices.

To manage and route this external traffic efficiently, we have an NGINX API Gateway positioned in front of the NodePort services. The NGINX API Gateway acts as the single entry point for all external HTTP requests. It is configured with specific HTTP routing rules to direct incoming requests to the appropriate NodePort, ensuring that the right microservices handle them.

This architecture allows us to maintain a secure and scalable API management layer while effectively utilizing the existing on-premise infrastructure.

What We Want To Achieve

Our goal is to ensure that the NodePort services in our on-premise Kubernetes cluster are only accessible by the NGINX API Gateway. We aim to restrict all external traffic so that any requests not originating from the NGINX API Gateway are denied. This security measure ensures that the microservices behind the NodePort are protected and that only authorized traffic, routed through the API Gateway, can interact with them.

Can it achieve with k8s network policy ? 👽

Overview Of K8s Network Policy

Kubernetes Network Policies are a set of rules used to control the traffic flow between pods within a Kubernetes cluster, as well as between pods and external endpoints. They define how pods communicate with each other and with the outside world, providing a way to enforce security at the network level.

Key Components of Network Policies

1. Pods and Namespaces:
   • Network policies are applied to specific pods within a namespace. A pod selector defines which pods the policy applies to.
   • Policies are defined at the namespace level but can target pods within any namespace.
2. Ingress and Egress Rules:
   • Ingress Rules: Control incoming traffic to the pods. They define which sources (pods, IP blocks, etc.) are allowed to send traffic to the selected pods.
   • Egress Rules: Control outgoing traffic from the pods. They specify which destinations (pods, IP blocks, etc.) the selected pods are allowed to send traffic to.
3. Selectors:
   • Pod Selector: A label selector that defines the group of pods to which the policy applies.
   • Namespace Selector: Defines which namespaces can send traffic to the selected pods (for ingress) or receive traffic from them (for egress).
4. Policy Types:
   • A policy can include Ingress, Egress, or both types of rules.
   • If no network policy is applied to a pod, the default behavior is to allow all traffic (both ingress and egress).
5. Controlling IP Blocks:
   • Network policies can specify IP blocks to control traffic based on IP addresses or ranges, allowing or denying traffic from specific external networks or subnets. This feature enhances security by enabling precise control over which external sources or destinations can interact with the pods.
6. Default Deny Policies:
   • By defining a network policy with no ingress/egress rules, you can create a "default deny" policy that blocks all traffic to/from the selected pods, except what is explicitly allowed by other policies.

Let’s test it out 🤔

k8s default network policy said we can allow/deny the network cidr blocks. It seems that it is a solution we are looking for to whitelist the nginx api gateway via k8s.

This diagram illustrates the expected behavior when a network policy is applied to whitelist the CIDR blocks of the NGINX API Gateway while blocking all other traffic. This ensures that all external traffic must route through the NGINX API Gateway before reaching the services.