Licensing

​

Format

• Signature scheme: EdDSA (RFC 8037 Ed25519).
• The radar-hub binary embeds the Skyhook-controlled public key at build time. The matching private key never leaves Skyhook’s secret store.
• Verified offline at boot - no network call required for the signature check itself.

​

Claims

{
  "iss": "skyhook",
  "aud": "radar-hub",
  "sub": "lic_acme_001",
  "iat": 1781000000,
  "nbf": 1781000000,
  "exp": 1812536000,
  "org": "Acme Corp",
  "tier": "enterprise",
  "max_clusters": 50,
  "features": ["sso", "audit-365d"]
}

​

How verification works

​

At boot

1. RADAR_HUB_LICENSE_KEY env var (preferred).
2. /etc/radar-hub/license file (Helm Secret mount).

• radar-hub: license verified - happy path. Same log line carries license id, org, tier, max_clusters, expiry.
• radar-hub: license is expired (warn-only - hub keeps serving) - signature OK, past exp. Continues serving.
• radar-hub: license verification failed - signature mismatch or missing required claim. Continues serving in warn-only mode for v1. Investigate immediately - this almost always means the wrong build talking to a real key, or vice versa.

• radar-hub: self-hosted mode but no RADAR_HUB_LICENSE_KEY (or /etc/radar-hub/license) - running in unlicensed mode (warn-only banner) - the JWT file/env wasn’t supplied. Set license.key in your Helm values or mount a Secret to /etc/radar-hub/license.

• radar-hub: embedded license public key is the all-zero placeholder; rebuild with the real key before shipping to a customer - the build wasn’t cut against the real Skyhook public key, so license verification cannot succeed against any real customer JWT. Only happens on a locally-built image - the official ghcr.io/skyhook-dev/radar-hub:<version> images embed the production public key. If you see this in production, you’re running an unofficial build; pull the published tag instead.

​

Warn-only enforcement

• A persistent yellow banner in the web app when verification has failed.
• Boot log lines visible to the operator.
• Heartbeat reports the issue back to Skyhook.

​

License heartbeat

• Endpoint: POST https://api.radarhq.io/v1/license/heartbeat
• Payload: license_id, hub_version, hub_mode, org_name, cluster_count, audit_event_count_24h, started_at.
• Response: optional renewed JWT, the latest published hub_version, optional message string.

• No cluster names, no user emails, no audit-event content.
• No customer Postgres data.
• No tunnel traffic.

​

Failure ladder

​

Rotation

• Heartbeat-renewed: the renewal response carries a new JWT. The control plane stores it in Postgres and uses it on next boot.
• Manual (fallback when heartbeat is disabled, or when your account team needs to push an out-of-cycle renewal): your account team emails a new JWT; you update the Helm value or Secret + roll the radar-hub Deployment.

helm upgrade radar-hub skyhook/radar-hub \
  --namespace radar-hub \
  --reset-then-reuse-values \
  --set license.key="<new JWT>"

# or, if you used existingSecret:
kubectl -n radar-hub create secret generic radar-hub-license \
  --from-literal=license="<new JWT>" --dry-run=client -o yaml | kubectl apply -f -
kubectl -n radar-hub rollout restart deploy/radar-hub-hub

​

Key rotation (Skyhook-side)

​

What you control

• The license JWT itself (rotate by upgrading the chart with a new value).
• Cookie sealing key (hub.cookiePassword) - independent from the license; rotating it just signs everyone out.
• The break-glass admin (always available, regardless of license state).

​

What Skyhook controls

• The signing private key.
• The license-server URL.
• The terms of the Subscription Agreement that backs warn-only enforcement.