Hello,
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
Thanks,
Dahn
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?
Thank you for answering.
@Amier I am interested in both: JWT token verification for a service exposed to North/South traffic and East/West traffic.
@karl-cardenas-coding I have practiced with Consul and tried the Consul intentions. This is great to allow/deny specific service to service communication. Is there a way to add JWT token verification in the consul sidecar of my api microservice for all the incoming requests ? I have created a JWT auth method but now I am not sure how to use it…
The JWT auth method gets you an ACL token, which is needed to participate in the service mesh. It sounds like what you are looking for is an application authentication mechanism, and that is outside the scope of Consul at the moment. In the future, that might change with the rapid development of Consul API Gateway.
I see, thank you for answering.
Is there a way to add and configure new http filters to the Envoy Proxy ? There is existing JWT authentication filters that can be configured in Envoy.
I have already used it in Kuma: Proxy Template | Kuma
They have a configuration file that can be used to add custom filters configuration to the Envoy Proxy. Then, this configuration is deployed to all the sidecar proxies.
Is there a similar feature with Consul ?
Thank you
Dahn
Hi @Dahnepfl,
Consul’s escape-hatch overrides could potentially be used to add JWT verification and processing to the inbound listeners for sidecar proxies.
Assuming you could get it to work, it would only apply to east-west traffic. Consul does not currently support installing escape hatch configurations on ingress gateways for north-south traffic. (see hashicorp/consul#8722).
The escape hatch is the closet thing Consul has to Kuma’s Proxy Template, or Istio’s EnvoyFilter resource, however I would not consider it equivalent because it does not support match, patch or remove operations. Certain hatches require a full replacement of the target configuration whereas others are only able to add additional configuration at the specified certain injection points.
We are open to improving the escape hatch to offer more flexibility like the ProxyTemplate or EvnoyFilter resources. I recommend filing a GitHub issue with details of your use case so that we can discuss and track this feature request.
Similarly to the escape hatch enhancements, we’re open to considering extending intentions to formally support JWT token auth. I’d also recommend commenting on the following GitHub issue with your use case so that our engineering team can review your requirements, and discuss how we might be able to support this.
Thanks.