Connecting a cluster

Connecting a cluster to Radar Cloud installs the same chart Radar OSS uses - just with cloud.enabled=true and a cluster credential. The Radar pod dials api.radarhq.io/agent over an outbound WebSocket; you don’t need any inbound rules on your cluster.

Three ways to start

From inside Radar. The Radar Cloud button in Radar’s top bar opens a dialog. On a local Radar with no authentication configured, the dialog runs the whole connection itself: it shows a plan of what will be installed, sends you to the browser to approve, then installs or adopts Radar in the cluster. Nothing talks to Radar Cloud until you have seen the plan. On any other setup - an in-cluster Radar, a local Radar with authentication on, a GitOps-managed install - the dialog explains what it found and links you to the wizard below, deep-linked at your namespace, release, or Argo CD / Flux owner where it could identify one.
From the terminal. radar cloud install does the same device flow from the command line: browser approval, credential minted for you, Radar installed or adopted. Use --hub-url for a Radar Cloud Self-Managed control plane.
From the dashboard. Generate a Helm command in app.radarhq.io and run it yourself - the rest of this page.

Get the install command

In app.radarhq.io, click Connect a cluster, name it (the underlying ID is opaque cl_...), then Generate install command. The page polls for connection while you run it. The command looks like:

helm repo add skyhook https://skyhook-io.github.io/helm-charts
helm repo update skyhook
kubectl create namespace radar --dry-run=client -o yaml | kubectl apply -f -
kubectl create secret generic radar-cloud-config -n radar \
  --from-literal=token=rhc_xxx... \
  --dry-run=client -o yaml | kubectl apply -f -
helm upgrade --install radar skyhook/radar -n radar \
  --set cloud.enabled=true \
  --set cloud.url=wss://api.radarhq.io/agent \
  --set cloud.insecureSkipVerify=false \
  --set cloud.clusterName=cl_xxx... \
  --set cloud.existingSecret=radar-cloud-config \
  --set auth.mode=proxy \
  --set rbac.helm=true \
  --set rbac.secrets=true \
  --set rbac.podExec=true \
  --set rbac.portForward=true \
  --set rbac.metrics=true \
  --set rbac.selfUpgrade=true

If your organization uses IdP groups for cluster access, the generated install disables the default role bindings. Apply the starter Kubernetes binding shown on the install page, using the groups and ClusterRole you want to grant access. Until you do, users cannot read the cluster through Radar.

The token is shown once. If you lose it before completing the install, generate a new command from the cluster’s row. The unused token stops working once the new one connects, or after 24 hours.

What each value does

Value	Effect
`cloud.enabled=true`	Switches the chart to cloud-mode (auth proxy, ClusterRoleBindings for `radar:*` groups, hardened listener).
`cloud.url`	The WebSocket endpoint to dial. `wss://api.radarhq.io/agent` for production.
`cloud.insecureSkipVerify`	Skips TLS verification of the control plane. Only for trials against a Self-Managed control plane with a self-signed certificate; always `false` for Radar Cloud.
`cloud.existingSecret`	The Secret holding the cluster token under the key `token`, so the token never appears in Helm values or release history. The token is a long-lived bearer credential identifying this cluster, revealed only once and SHA-256 hashed at rest by the control plane. See Cluster tokens.
`cloud.clusterName`	The opaque cluster ID assigned by the control plane. The Radar pod advertises this on handshake.
`rbac.helm`	Enables Helm install / upgrade / rollback / uninstall. Auto-enables `rbac.secrets`. In Cloud mode, Helm runs as the signed-in user: Radar allows Helm writes in a namespace only if that user can create Secrets there (Helm runs as you). With `cloud.defaultRbac.create=true`, it also binds `radar-helm` to the owner and member tiers and `radar-helm-admin` to owner only.
`rbac.secrets`	Allows the resource browser to show Secrets.
`rbac.podExec`	Enables the pod terminal and debug containers.
`rbac.portForward`	Enables port forwarding through the UI.
`rbac.metrics`	Reads CPU and memory metrics from metrics-server for the dashboard and resource panels.
`rbac.selfUpgrade`	Lets Radar Cloud upgrade this Radar from the UI. Scoped to patching the one Radar Deployment.
`auth.mode=proxy`	Matches the auth mode cloud-mode runs in, so every Helm RBAC binding for the `radar:*` groups renders.

Set any rbac.* flag to false to restrict what Radar can do in your cluster - the UI gracefully degrades. In cloud mode Radar can always read Secrets, and each user sees only the Secrets their own Kubernetes RBAC allows. See In-cluster deployment for the full list.

What the chart deploys

Namespace: radar
├─ Deployment: radar            # the OSS binary in cloud-mode
├─ ServiceAccount: radar
├─ ClusterRole / ClusterRoleBinding (read access + opt-ins)
├─ ClusterRoleBindings:
│   radar:owner     → admin       ┐
│   radar:member    → edit        ├ not with defaultRbac.create=false
│   radar:viewer    → view        ┘
│   radar:system    → view + cluster-read + integration-read + Secret read
│                     (Radar Cloud alerts and timeline)
│   radar:ai:reader → view-based read + cluster-read + integration-read
│                     (alert-triggered AI investigations)
└─ Service / NetworkPolicy (optional)

Alerts and the timeline use a separate background identity. AI investigations use your access for requests you make and a dedicated group for alert-triggered turns. There’s no Service exposed to the outside - the Radar pod only needs outbound TLS to api.radarhq.io:443. No ingress, no LB, no DNS.

Verify the connection

Inspect the installation from any machine with access to the cluster:

radar cloud status --context my-cluster

The command reports the detected Helm or GitOps installation, chart and image, agent readiness, Cloud configuration, Hub URL, configured cluster reference, and the cluster ID and tunnel state reported by the Hub. It is read-only and never prints the connection token. If Radar finds multiple installations, select one with --namespace and --release. To check the tunnel, Radar reads the token from the Kubernetes Secret referenced by the Deployment and sends it directly to the configured Hub. A confirmed disconnected tunnel or rejected token makes the command fail. If your Kubernetes identity cannot read that Secret, or the Hub cannot be reached, the tunnel check is shown as unavailable while the local installation diagnostics still run. The install page polls for up to 5 minutes. Once connected, you’ll be redirected into the cluster view. If polling times out:

# Radar pod logs
kubectl logs -n radar deploy/radar

# Look for:
[cloud] connected to wss://api.radarhq.io/agent as cl_xxx...
[cloud] handshake ok, cluster status -> connected

Common failures:

Symptom	Likely cause
`401 unauthorized` on handshake	Token invalid or rotated. Generate a new install command.
`connection refused`	Egress firewall blocking outbound `api.radarhq.io:443`.
`TLS handshake failure`	Outbound proxy doing TLS inspection without the corporate CA injected into the Radar pod’s trust store.
Connects then drops	The Radar pod must run on a single replica; check for crash loops via `kubectl describe pod`.

Reinstall vs. rotate

Reinstall - re-run the same Helm command with a fresh token. Used when you’ve lost the original install yaml.
Rotate token - issues a new token without changing the cluster ID. By default the previous token keeps working until Radar connects with the new one (or for 24 hours), so the cluster stays online. Turn on Revoke the current token immediately when you suspect a leak.

See Cluster token rotation for both flows.

Keep Radar up to date

Radar Cloud’s dashboard is always the latest release, while each cluster runs the Radar version it was installed or last upgraded with. The Clusters page shows each cluster’s version and marks it when a newer release exists.

One-click upgrade - an organization owner can upgrade a connected cluster from the Clusters page when its install allows self-upgrade (the default). Radar restarts and reconnects on the new version.
Helm or GitOps - when self-upgrade is off, upgrade through the Helm release or the GitOps source that manages Radar. The Clusters page says so for that cluster.
When a page needs a newer Radar - a page or section that relies on a newer Radar than the cluster runs says so, instead of failing. Upgrade Radar opens the Clusters page at that cluster’s row.
Out-of-date clusters - when a cluster’s Radar is four or more minor releases behind, its top bar shows Radar out of date, linking to the same place.

Egress requirements

Destination	Port	Why
`api.radarhq.io`	443	The control-plane WebSocket.
Container registry that hosts the chart / image	443	Pulling the Radar image. Default `ghcr.io/skyhook-io/radar`.

Air-gapped clusters

Cloud assumes outbound TLS to api.radarhq.io. Air-gapped environments can run Radar OSS, the same UI without a control plane, or Radar Cloud Self-Managed with the control plane inside your network.

Get started

Views

In-cluster capabilities

Integrations

Local & in-cluster setup

Cloud

Reference

Connecting a cluster

Three ways to start

Get the install command

What each value does

What the chart deploys

Verify the connection

Reinstall vs. rotate

Keep Radar up to date

Egress requirements

Air-gapped clusters

See also

​Three ways to start

​Get the install command

​What each value does

​What the chart deploys

​Verify the connection

​Reinstall vs. rotate

​Keep Radar up to date

​Egress requirements

​Air-gapped clusters

​See also

Three ways to start

Get the install command

What each value does

What the chart deploys

Verify the connection

Reinstall vs. rotate

Keep Radar up to date

Egress requirements

Air-gapped clusters

See also