[🐛 Bug]: Cilium provider improvements — hubble connection config and service naming in topology

[gecube]

Summary

I successfully managed to get Cilium working with KeepHQ on a test k3s cluster.
To connect to Hubble, I used the following configuration:

...
  provision:
    providers:
      ...
      cilium:
        type: cilium
        authentication:
          cilium_base_endpoint: hubble-relay.kube-system.svc.cluster.local:80

This configuration works perfectly and should be documented, since connecting via localhost (as shown in examples) looks more like a workaround than a recommended approach.

---

🧩 Suggested documentation improvement

• Add an example for in-cluster Hubble connection using
  cilium_base_endpoint: hubble-relay.kube-system.svc.cluster.local:80.
• Clarify that in a default setup, Hubble does not use TLS, meaning:
  • The default Hubble installation is not production-ready out of the box.
  • At minimum, Hubble should be protected by a NetworkPolicy or configured with TLS for secure use.

---

🧠 Observations during testing

After configuring the provider, I was able to obtain a network topology map of services using Hubble data.
However, the results are not yet fully usable for real visibility, as:

• All Kubernetes Services (kind: Service) are shown as IP addresses instead of their cluster service names.
• Services are not automatically enriched with labels or linked to corresponding applications, even though this information is available in the Kubernetes API.

---

📊 Examples

Example from CoreDNS (should be shown as kube-dns instead of 10.43.0.10):

kube-system                 kube-dns       ClusterIP   10.43.0.10   <none>   53/UDP,53/TCP,9153/TCP

Example from KeepHQ backend (should appear as keep-backend instead of 10.43.43.195):

keephq                      keep-backend   ClusterIP   10.43.43.195 <none>   8080/TCP

---

💡 Expected behavior

1. Instead of plain IP addresses, show service names for internal cluster traffic (e.g. kube-dns, keep-backend, etc.).
2. For external traffic, display FQDN where available.
3. Automatically group services and pods by Kubernetes labels (e.g. app.kubernetes.io/name, app, component, keep-component, etc.)
   to enrich and structure the service topology.

---

✅ Proposed improvements

Functional

• Add a mapping layer in the topology builder that resolves Service IPs to Service.metadata.name when found in the same cluster.
• Enrich nodes with Kubernetes labels to associate workloads with applications.
• Optionally, introduce a setting to control how aggressively topology enrichment is performed (for performance considerations).

Documentation

• Update the Cilium provider page to include:
  • Example of in-cluster connection via hubble-relay.kube-system.svc.cluster.local:80.
  • A warning about Hubble’s default lack of TLS.
  • A note that localhost examples are primarily for local testing.

---

🧠 Rationale

• Improves usability and accuracy of service topology visualization.
• Makes the Cilium provider practical for real-world cluster monitoring.
• Clarifies proper configuration and security considerations for users.

---

Labels: type:enhancement area:providers-cilium priority:medium