Consul ACL scope


I am interested in JWT and claims verifications/authorization at the sidecar microservice level. This verification will only allow verified traffic to the microservice.
I have read a lot about the Consul ACLs, but it seems that this is done only to authorize connections to manage Consul Systems (Consul Agent, Consul Cli etc…). Is it also possible to use Consul ACLs for service-to-service communication ? Something similar to Istio JWT token authentication: Istio / JWT Token



Hi @Dahnepfl you can control which services are allowed to communicate to one another through Consul intentions. Intentions are rules that specify which service is allowed to communicate with another service. However, in order to take advantage of this capability, the service needs to be registered in Consul and have a Consul client and sidecar proxy (Envoy) deployed alongside. Once a service is registered in Consul, the sidecar, Envoy, will allow traffic to and from a service if a Consul intention permits the communication.

Now, you mentioned ACLs. ACLs are not required to use Consul intentions. But we strongly recommend enabling ACLs to protect your services and the service mesh.

ACLs are the authorization mechanism for the Consul agent to participate in the Consul service mesh. You can think of the ACL as the ticket to participate in the service mesh, without a valid ACL token the Consul agent cannot participate in the service mesh.

So to wrap up this response, you would use Consul intentions to authorize the service-to-service communication. And to ensure only authorized entities or resources are allowed into the service mesh, you would enforce ACLs.

Hope this helps.

Thanks for throughly answering this @karl-cardenas-coding !

@Dahnepfl I’m interested to hear more about this use case, are you interested in using JWT tokens for just North/South traffic or also East/West?