Authentication

This provider requires authentication.

  • cilium_base_endpoint: The base endpoint of the cilium hubble relay (required: True, sensitive: False)

In workflows

This provider can’t be used as a “step” or “action” in workflows. If you want to use it, please let us know by creating an issue in the GitHub repository.

Topology

This provider pulls topology to Keep. It could be used in correlations and mapping, and as a context for alerts and incidents.

Overview

Cilium provider is in Beta and is not working with authentication yet.

The current way to pull topology data from your kubernetes cluster, is to run:

# hubble-relay usually installed at kube-system, but it depends on your cluster.
kubectl port-forward -n kube-system svc/hubble-relay 4245:80

and then use localhost:4245 to pull topology data.

If you need help with connecting Cilium provider, reach out.

The Cilium provider leverages Hubble’s network flow data to automatically discover service dependencies and build a topology map of your Kubernetes applications.

Authentication Parameters

ParameterDescriptionExample
cilium_base_endpointThe base endpoint of the Cilium Hubble relaylocalhost:4245

Outputs

The provider returns topology information including:

  • Service names and their dependencies
  • Namespace information
  • Pod labels and cluster metadata
  • Network-based relationships between services

Service Discovery Logic

The provider identifies services using the following hierarchy:

  1. Workload name (if available)
  2. Kubernetes labels (k8s:app= or k8s:app.kubernetes.io/name=)
  3. Pod name (stripped of deployment suffixes)

Requirements

  • A running Kubernetes cluster with Cilium installed
  • Hubble enabled and accessible via gRPC
  • Network visibility (flow logs) enabled in Cilium

Limitations

  • Only captures active network flows between pods
  • Service discovery is limited to pods with proper Kubernetes labels
  • Requires direct access to the Hubble relay endpoint

Google Kubernetes Engine specific

If you are using a GKE cluster, you cannot connect Keep to the Google-managed hubble-relay directly because:

  • hubble-relay operates only in secure mode,
  • hubble-relay requires client certificate authentication.

However, Keep does not currently support these features.

To work around this, you can add an NGINX Pod that listens on a plaintext HTTP port and proxies requests to hubble-relay secure port using hubble-relay certificates.

You need a GKE cluster with dataplane v2 .

Dataplane v2 observability must be enabled.

Here is an example of running a plaintext NGINX proxy:

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: hubble-relay-insecure-nginx
  namespace: gke-managed-dpv2-observability
data:
  nginx.conf: |
    user  nginx;
    worker_processes  auto;

    error_log  /dev/stdout notice;
    pid        /var/run/nginx.pid;

    events {
      worker_connections  1024;
    }

    http {
      log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
      '$status $body_bytes_sent "$http_referer" '
      '"$http_user_agent" "$http_x_forwarded_for"';

      access_log /dev/stdout main;

      server {
        listen       80;

        http2 on;

        location / {
          grpc_pass grpcs://hubble-relay.gke-managed-dpv2-observability.svc.cluster.local:443;

          grpc_ssl_certificate /etc/nginx/certs/client.crt;
          grpc_ssl_certificate_key /etc/nginx/certs/client.key;
          grpc_ssl_trusted_certificate /etc/nginx/certs/hubble-relay-ca.crt;
        }
      }
    }
---
kind: Deployment
apiVersion: apps/v1
metadata:
  name: hubble-relay-insecure
  namespace: gke-managed-dpv2-observability
  labels:
    k8s-app: hubble-relay-insecure
    app.kubernetes.io/name: hubble-relay-insecure
    app.kubernetes.io/part-of: cilium
spec:
  replicas: 1
  selector:
    matchLabels:
      k8s-app: hubble-relay-insecure
  template:
    metadata:
      labels:
        k8s-app: hubble-relay-insecure
        app.kubernetes.io/name: hubble-relay-insecure
        app.kubernetes.io/part-of: cilium
    spec:
      securityContext:
        fsGroup: 1000
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: frontend
          image: nginx:alpine
          ports:
            - name: http
              containerPort: 80
          volumeMounts:
            - name: hubble-relay-insecure-nginx-conf
              mountPath: /etc/nginx/
              readOnly: true
            - name: hubble-relay-client-certs
              mountPath: /etc/nginx/certs/
              readOnly: true
      volumes:
        - configMap:
            name: hubble-relay-insecure-nginx
          name: hubble-relay-insecure-nginx-conf
        - name: hubble-relay-client-certs
          projected:
            defaultMode: 0400
            sources:
              - secret:
                  name: hubble-relay-client-certs
                  items:
                    - key: ca.crt
                      path: hubble-relay-ca.crt
                    - key: tls.crt
                      path: client.crt
                    - key: tls.key
                      path: client.key
---
kind: Service
apiVersion: v1
metadata:
  name: hubble-relay-insecure
  namespace: gke-managed-dpv2-observability
  labels:
    k8s-app: hubble-relay-insecure
    app.kubernetes.io/name: hubble-relay-insecure
    app.kubernetes.io/part-of: cilium
spec:
  type: ClusterIP
  selector:
    k8s-app: hubble-relay-insecure
  ports:
    - name: http
      port: 80
      targetPort: 80

Now you can connect Keep with google-managed hubble-relay by adding Cilium provider using hubble-relay-insecure.gke-managed-dpv2-observability:80 address.