Consul sidecar with service-discovery

Consul
, ,
1

I want configure mtls and enforce connection between services.

In order for the services to start communicating via envoy with this, I need to configure the consul annotation upstream: ‘api: 4000’, then the web will be able to access the api via localhost: 4000. After that, I will be able to configure intentions, but intention will only work on localhost: 4000. And if you access the api through the domains that service discovery creates, for example api. default.svc, api.service.consul, then web will ignore envoy and go directly to the api, therefore, no mtls and intention does not work.

Demonstrate that on practice:
Create to pods static-client and static-server

metadata:
  name: static-client
  annotations:
    'consul.hashicorp.com/connect-inject': 'true'
    'consul.hashicorp.com/connect-service-upstreams': 'static-server:1234'

metadata:
  name: static-server
  annotations:
    'consul.hashicorp.com/connect-inject': 'true'

$: kubectl get pods
NAME            READY   STATUS    RESTARTS   AGE
static-client   3/3     Running   0          155m
static-server   3/3     Running   0          155m

Check connection from static-client to static-server, without intentions:

$: k exec -it static-client -c static-client -- /bin/bash
static-client$: curl localhost:1234
"hello world"
static-client$: curl static-server.service.consul:8080
"hello world"
static-client$: curl static-server.api.svc.cluster.local:8080
"hello world"

Create intention:

$: consul intention match -destination static-server
static-client => static-server (deny)

Check connection from static-client to static-server, with intentions:

static-client$: curl localhost:1234
curl: (52) Empty reply from server
static-client$: curl static-server.service.consul:8080
"hello world"
static-client$: curl static-server.api.svc.cluster.local:8080
"hello world"

How to combine service discovery and sidecar in consul?

2

Hi @Pepsi1k,

In order to prevent direct access to your services (i.e., bypassing the sidecar) you would need to configure your app to only listen on a loopback address so that it is not accessible from the pod IP, and only accessible from the local proxy.

We are hoping to address this in the next release of Consul by adding support for transparent proxying which will use iptables to redirect traffic to/from the app through the proxy in order to ensure that mTLS and intentions are enforced for all connections. With this change, you would no longer need to configure your application to talk to a specific port on localhost, or use some alternate method of service discovery. iptables would take care of appropriately routing the traffic to the sidecar.

We are tracking this feature request in GitHub issue hashicorp/consul-k8s#23. I recommend upvoting :+1: the issue to show your interest, and optionally subscribing to it updates on its development status.

1 Like