consideRatio
commented
4 years ago @williamsandrew thanks for reporting this! I ran into this as well. I figure it would be useful to be able to reproduce this for anyone that knows enough to try resolve this, and here is how.
My environment
Ubuntu 20.04, k3s v1.17.4+k3s1 (3eee8ac3) with --docker, and docker version 19.03.8.
Reproduction script
Toggle me
```shell echo "Installing k3s..." curl -sfL https://get.k3s.io | sh -s - \ --write-kubeconfig-mode=644 \ --disable metrics-server \ --disable traefik \ --disable local-storage \ --docker echo "Installing a networkpolicy, service, and deployment for an echoserver ..." cat << EOF | k3s kubectl apply -f - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: echoserver spec: podSelector: matchLabels: app: echoserver policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: echoserver-access: "true" --- apiVersion: v1 kind: Service metadata: name: echoserver spec: ports: - port: 80 targetPort: 8080 selector: app: echoserver --- apiVersion: apps/v1 kind: Deployment metadata: name: echoserver spec: selector: matchLabels: app: echoserver template: metadata: labels: app: echoserver spec: containers: - name: echoserver image: gcr.io/google_containers/echoserver:1.10 ports: - containerPort: 8080 EOF echo "waiting for the deployed echoserver to be ready ..." k3s kubectl rollout status --watch deploy/echoserver echo "Trying to access echoserver without the correct label for access..." k3s kubectl run -it --rm --restart=Never --image=busybox --generator=run-pod/v1 busybox-without-access -- sh -c 'while ! wget -q -O- http://$ECHOSERVER_SERVICE_HOST; do sleep 5; done' echo "Waiting two minutes to see if something changes..." sleep 120 echo "Trying to access echoserver with the correct label for access..." k3s kubectl run -it --rm --restart=Never --image=busybox --generator=run-pod/v1 --labels=echoserver-access=true busybox-with-access -- sh -c 'while ! wget -q -O- http://$ECHOSERVER_SERVICE_HOST; do sleep 5; done' ```Observation
The busybox-without-access had access, and then after waitin for two minutes, the busybox-with-access failed to get access during the initial ~40 seconds, and then got access.
I see two issues which may relate:
- Briefly after k3s cluster creation (<3 min), the network policy controller doesn't seem to be active, and allows access to a pod targeted by a network policy and should not be allowed to be accessed.
- With a fully started k3s cluster, but in a recently started container with access to another pod thanks to a k8s label allowing it, the network policy controller denies access for ~40 seconds and then finally allows it.
erikwilson
wilsonianb
ShylajaDevadiga
msmith93
brandond
cpg314
Version:
k3s version v0.10.0 (f9888ca3)Describe the bug There appears to be period of time (<1 minute) after a pod is started during which applicable network policies are not enforced.
To Reproduce Steps to reproduce the behavior: https://github.com/ahmetb/kubernetes-network-policy-recipes/blob/master/11-deny-egress-traffic-from-an-application.md
Expected behavior All egress requests (via
wget) from theapp=foolabeled pod should fail with eitherbad addressordownload timed out(depending on the network policy in use).Actual behavior Egress requests (via
wget) from theapp=foolabeled pod initially succeed after pod startup before eventually failing as expected.Additional context