If you discover a security vulnerability in Kube Workspaces, please report it responsibly. Do not open a public GitHub issue for security vulnerabilities.
Email: security@kubeworkspaces.io
Alternatively, use GitHub's private vulnerability reporting on the relevant repository.
- Description of the vulnerability
- Steps to reproduce
- Affected component(s): controller, api, proxy, frontend
- Impact assessment (what an attacker could achieve)
- Any suggested fix (optional)
- Acknowledgement: Within 48 hours
- Initial assessment: Within 7 days
- Fix timeline: Depends on severity, typically within 30 days for critical issues
The following are in scope:
- Authentication bypass (OIDC flow, session validation, cookie handling)
- Authorization bypass (namespace access, role escalation)
- Proxy request smuggling or path traversal
- CRD injection or privilege escalation via workspace specs
- Information disclosure (secrets, tokens, user data)
- Denial of service against the control plane components
- Vulnerabilities in workspace container images themselves (these are user-configured)
- Issues requiring physical access to the cluster nodes
- Social engineering attacks
- Vulnerabilities in dependencies that are already publicly disclosed (open a regular issue instead)
| Version | Supported |
|---|---|
| Latest release | Yes |
| Previous minor | Best effort |
| Older | No |
Kube Workspaces handles sensitive operations:
- Authentication: OIDC-based with HMAC-SHA256 signed session cookies
- Authorization: CRD-based roles (admin/editor/viewer) with namespace-level access control
- Proxy: Routes browser traffic to workspace pods with session validation
- No database: All state in Kubernetes CRDs and Secrets (encrypted at rest via cluster config)
For architecture details, see the proxy documentation and authentication documentation.