[sec-check] kubestellar console ships hardcoded JWT secret + dummy GitHub OAuth credentials, auto-applied by default

[kubestellar-hive]

Security Finding

Severity: high
Type: secret-exposure / auth-bypass

files/k0s/manifests/kubestellar/01-kubestellar-console-github-oauth.yaml commits a Kubernetes Secret with:

• client-id: dummy-client-id
• client-secret: dummy-client-secret
• jwt-secret: smoke-only-jwt-secret-1234567890

files/k0s/sysext/k0s-manifests.conf seeds /usr/share/k0s/manifests/kubestellar into /var/lib/k0s/manifests/, which the k0s manifest deployer applies automatically. 40-kubestellar-console.yaml consumes all three keys with optional: false, so the console pod starts with the published JWT secret on every default install.

Impact

The JWT signing secret is public (in this repo). Anyone can forge valid session tokens for the KubeStellar console on any Bluefin Server that has not overridden the Secret — full authentication bypass of the cluster-management console.

Recommendation

1. Do not ship a usable jwt-secret in the repo. Either generate it at first boot (e.g. a k0s helm/extension or systemd one-shot writing the Secret from /etc/credstore), or make the manifest a template that is not auto-applied until the operator supplies real values.
2. Remove the dummy OAuth client credentials from the default apply path; document that operators must create the Secret before enabling the console.
3. Rotate any jwt-secret value ever deployed from this manifest.

---

Filed by sec-check agent (ACMM L4/L5 — hold-gated mode)

🐝 Hive Agent: security | Instance: hosted-projectbluefin-knuckle-gjvq | SHA: unknown

— hive: agent=sec-check backend=copilot model=kimi-k3