Hi Team,
I have installed Consul OSS in our EKS 1.24 cluster (as describe in the attached file name "
.yml",
After this installation, I have also installed a Test application (https://github.com/hashicorp-education/learn-consul-get-started-kubernetes/tree/main/self-managed/eks/hashicups/v1), to verify that mesh will show me the service upstream and downstream as it should be without the need to add intentions in the Transparent mode, as it is by default. Unfortunately, I was unable to see any mesh between the services.
I have then upgrade my configuration with this new setting “Consul-staging - Second configuration.yml” by making consul secure (ACL, gossiEncryption, TLS).
For this configuration as I understood, all communication between service are disable because ACL and a definition of Intentions help to allow communications between services.
For the described testing app above, I have enabled the intentions and were able to see the service mesh (upstream and downstream).
I have made a lot of research and figured out that there is currently a lot of example of the Hashicups testing app. This does not help us to understand and see the result.
Could you please guide me what kind of configuration is needed to discover the upstream and downstream of the service before to set the intentions (I believe this should be the default configuration of a service mesh tool).
Hi @phardelain.kouassi,
Welcome to the HashiCorp Forums!
If I understand correctly, after installing the Consul cluster and the hashicups application in a non-ACL cluster, you could not see the hierarchy/dependency of services in the topology UI. Please correct me if this is not right.
The reason behind this is due to the way transparent proxy works. The downstream-to-upstream dependency is set using intentions in the case of transparent proxy. In a non-ACL cluster with transparent proxy, Consul would allow any-to-any communication (unless explicitly denied by intentions). This is why the topology view shows every service having a dependency on the other.
On the other hand, if you register services using explicit upstream (non-transparent proxy scenario), the downstream-to-upstream dependency is explicitly defined by annotation at the time of registration, which would populate the topology view correctly.
This guide will help you understand the non-transparent proxy workflow: Secure applications with service sidecar proxies | Consul | HashiCorp Developer
You can get the same effect on a non-ACL cluster with a transparent proxy as an ACL-enabled cluster by setting an ALL-to-ALL Service deny intention and then explicitly putting the required allow intentions.
Could you please guide me what kind of configuration is needed to discover the upstream and downstream of the service before to set the intentions (I believe this should be the default configuration of a service mesh tool).
Finally, I think this is not the right approach. The decision to set the intentions should be based on the knowledge of the service dependency.
I hope this helps.
