Consul On Minikube vs Consul On Kubeadm

I am new to consul and following consul on minibike with helm exercise. i am able to deploy consul(on minikube) and successfully tested the intention with sample counting and dashboard applications as per the guide.

To take my learning a bit further, i tried to deploy consul on kubernetes cluster(installed via kubeadm with 1 master and 2 worker nodes) with weave-net as CNI Plugin. All the Consul related Pods(server,client,connect-injector-webhook) are deployed and able to see the consul UI, Verified services getting registered.

However, the deny intention between dashboard and counting apps is not working. Even after deny intention is configured, the dashboard app can able to talk to counting app.

I am uploading 2 log files , one captured on minikube and other on kubernetes consul server pod
minikubeconsulserverlogs.txt.txt (19.5 KB) kubeadmconsulserverlogs.txt.txt (7.9 KB) c

I didn’t see any major differences between logs captured as i see POST request when intention is configured and DELETE request when intention is deleted. But previously when i tried to analyse logs on minikube, i saw agent.envoy related logs like below which i didn’t saw on kubeadm setup:

2020-07-04T16:30:39.811Z [DEBUG] agent: Check status updated: check=service:counting-counting-sidecar-proxy:1 status=passing
2020-07-04T16:30:41.636Z [DEBUG] agent.envoy: generating cluster for: cluster=counting.default.minidc.internal.fe61dd2b-6b2f-4b41-f77c-b04273a378ed.consul
2020-07-04T16:30:41.636Z [DEBUG] agent.envoy: generating endpoints for: cluster=counting.default.minidc.internal.fe61dd2b-6b2f-4b41-f77c-b04273a378ed.consul
2020-07-04T16:30:42.199Z [DEBUG] agent.envoy: Connect AuthZ ALLOWED: source=spiffe://fe61dd2b-6b2f-4b41-f77c-b04273a378ed.consul/ns/default/dc/minidc/svc/dash
2020-07-04T16:30:42.504Z [DEBUG] agent: Check status updated: check=service:dashboard-dashboard-sidecar-proxy:1 status=passing

Sorry for the lengthy message.
Looking forward to the community help. Do let me know if you need any additional information.

Hi, so to be clear this is working on minikube but not on your other kube cluster?

What happens when you run consul intention check dashboard counting?

What happens if you redeploy the dashboard app after setting the deny intention? One thing to note is that if the connection is persisted, the new intention will not apply, it only applies on a new connection.

Here is the output for the command:

/ # consul intention check dashboard counting

I tried redeploying dashboard but still the deny intention didn’t triggered.