Networkpolicy
Fleeting- External reference: https://kubernetes.io/docs/concepts/services-networking/network-policies/
Instructions in k8s pour tell what pod can access what service, base of IP address ranges or pod or namespaces labels.
podSelector: This selects particular Pods in the same namespace as the NetworkPolicy
— https://kubernetes.io/docs/concepts/services-networking/network-policies/
namespaceSelector: This selects particular namespaces for which all Pods should be allowed as ingress sources or egress destinations.
— https://kubernetes.io/docs/concepts/services-networking/network-policies/
Allow all ingress traffic If you want to allow all incoming connections to all pods in a namespace, you can create a policy that explicitly allows that.
service/networking/network-policy-allow-all-ingress.yaml
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all-ingress spec: podSelector: {} ingress:
- {}
policyTypes:
- Ingress
With this policy in place, no additional policy or policies can cause any incoming connection to those pods to be denied. This policy has no effect on isolation for egress from any pod.
— https://kubernetes.io/docs/concepts/services-networking/network-policies/
By default, a pod is non-isolated for ingress; all inbound connections are allowed. A pod is isolated for ingress if there is any NetworkPolicy that both selects the pod and has “Ingress” in its policyTypes; we say that such a policy applies to the pod for ingress. When a pod is isolated for ingress, the only allowed connections into the pod are those from the pod’s node and those allowed by the ingress list of some NetworkPolicy that applies to the pod for ingress. The effects of those ingress lists combine additively.
— https://kubernetes.io/docs/concepts/services-networking/network-policies/
When in doubt, use kubectl describe to see how Kubernetes has interpreted the policy
— https://kubernetes.io/docs/concepts/services-networking/network-policies/
from/to elements are in “or” logic
… ingress:
- from:
- namespaceSelector: matchLabels: user: alice podSelector: matchLabels: role: client
…
contains a single from element allowing connections from Pods with the label role=client in namespaces with the label user=alice. But this policy:
… ingress:
- from:
- namespaceSelector: matchLabels: user: alice
- podSelector: matchLabels: role: client
…
contains two elements in the from array, and allows connections from Pods in the local Namespace with the label role=client, OR from any Pod in any namespace with the label user=alice.
— https://kubernetes.io/docs/concepts/services-networking/network-policies/
networkpolicy cannot target a namespace by its name
While NetworkPolicy cannot target a namespace by its name with some object field, you can use the standardized label to target a specific namespace. […] The Kubernetes control plane sets an immutable label kubernetes.io/metadata.name on all namespaces, provided that the NamespaceDefaultLabelName feature gate is enabled. The value of the label is the namespace name
— https://kubernetes.io/docs/concepts/services-networking/network-policies/
Notes linking here
- cilium
- flannel
- how to debug a connection issue in k8s?
- how to organise the inter subchart networkpolicies?
- k3d