![]() But first lets see how we can configure iptables at a given time to reflect current state of network policies. In later section we will see how this poses challenges in how delta changes to iptable configuration applied with minimal disruption to datapath. Pods being ephermal in nature, set of pods matching the label selector is a dynamic set. ![]() ![]() Essentially a network policy implicitly evaluates to be definition of set of source pods that can talk to set of destination pod over specified port and protocol. So its easy to get the set of source pod IP’s and set of destination pod IP’s based on the matchLables in network policy spec. Kubectl get pods -o json -selector=app=guestbook,tier=frontend -namespace=testns1 | jq '.items |. ![]() Kubernetes provides a convenient way to retrieve the set of pods matching a label selector through API or kubectl as shown below. So its implementation of network policies responsibility to translate the intent to configuration. Network policies are declarative in nature to express application intent. Ports section of network policy spec defines one or more port and protocol combinations that are to be opened up. Alternatively namespaceSelector in the ingress section can be used to select all pods in a namespace. Similarly ingress section of network policy has a matchLabels in podSelector section which identifies the set of pods that will become source pods set. In the network policy matchLabels in podSelector section is used to identify set of destination pods for which a network policy applies. A typical network policy looks like below: apiVersion: extensions/v1beta1 Network policies build up on labels and selectors which are key concepts of Kubernetes that are used to organize (for e.g all DB tier pods of app) and select subsets of objects. There are no explicit CIDR or IP used for matching source or destination IP’s. Kubernetes network policies are application centric compared to infrastructure/network centric standard firewalls. Lets quickly recap what network policies are then we will dive in to the iptables based solution aspects. Lets see quick demo of network policies in action when a namespace is configured with DefaultDeny isolation type, network policies can be configured in the namespace to whitelist the traffic to the pods in that namespace.When a namespace is configured with isolation tye of DefaultDeny no traffic is allowed to the pods in that namespace default allow behaviour can be changed to default deny on per namespace basis.for every pod by default ingress is allowed, so a pod can receive traffic from any one.Kubernetes networking has following security model: But concepts described can be used to build your own version of network policy enforcer with iptables. This write up draws up from the insights of implementing a network policy controller in Kube-router. Intent of this blog post is not to describe what network policies are but to show how iptables on the the cluster nodes can be used to build a distributed firewall solution that enforces network policies in Kubernetes clusters. Network policies in Kubernetes provides primary means to secure a pod by exerting control over who can connect to pod.
0 Comments
Leave a Reply. |