Allowing ingress from Kubernetes API via service selector doesn't work
Expected Behavior
I'd expect the following policy to allow ingress from the Kubernetes API to a mutating webhook service:
apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
name: allow-webhook-ingress
namespace: webhook
spec:
selector: app = 'webhook'
types:
- Ingress
ingress:
- action: Allow
protocol: TCP
source:
services:
name: kubernetes
namespace: default
destination:
ports:
- 9443
Current Behavior
Requests from the Kubernetes API keep getting blocked.
Steps to Reproduce (for bugs)
- Apply the above policy to a mutating webhook service
- Trigger a request to the webhook service
Your Environment
- Calico version: 3.21.6
- Orchestrator version (e.g. kubernetes, mesos, rkt): Kubernetes 1.23.5
- Operating System and version: AKS
@Tolsto I'd expect that to work as well, unless your Kubernetes API endpoints are behind some sort of NAT or in general do not match the endpoints listed in kubectl get endpointslices.
apiVersion: crd.projectcalico.org/v1
I'd be remiss if I didn't call out this issue as well: https://github.com/projectcalico/calico/issues/6412
❯ kubectl get endpointslices
NAME ADDRESSTYPE PORTS ENDPOINTS AGE
kubernetes IPv4 443 10.20.232.7 38d
Output is what I'd expect. It's a vanilla AKS setup with Calico.
Ah, I suspect the problem is that on AKS the API server(s) is hidden behind a load balancer, so outbound traffic is sent to 10.20.232.7, but inbound traffic from the API server(s) arrive on different addresses. Might be worth it to see if you can catch one of the packets as it arrives and see what it's source address is.
@Tolsto did you happen to get a chance to test @caseydavenport 's theory?
Closing for inactivity. Please reopen if needed.