Kubernetes API proxy and secrets

Loopback can proxy Kubernetes API calls server-side using credentials and kubeconfig material stored for the workspace, while enforcing Loopback RBAC before any cluster call. This is distinct from kubectl with a downloaded kubeconfig: the proxy path is how console views and automation integrate without shipping cluster-admin files to browsers.

Proxy surface (workspace routes)

Dedicated Kubernetes API proxy modules expose read and mutate operations such as:

• Cluster summary, nodes, ingress, load balancer services, Helm releases, volumes.
• Cordon / uncordon / drain helpers.
• Events and deployments listings.

Each call is authorized with workspace-scoped Kubernetes permissions before issuing Kubernetes client requests.

Kubernetes secrets workflow

A secrets capability gates create-from-form, rotation, and read workflows for Secret objects through Loopback. Treat granted roles as cluster credential access because secret payloads may contain application credentials or TLS keys.

Workspace Kubernetes settings

Workspace Kubernetes settings aggregate version, upgrade availability, OIDC toggles, and operational flags surfaced to project members.

Safety expectations

• Loopback RBAC is not Kubernetes RBAC: you need both aligned for safe delegation.
• Audit hooks exist on sensitive routes (kubeconfig download, maintenance changes); confirm your deployment exports audit logs to SIEM.

Related reading

• Kubernetes operations
• Access and cluster basics
• Access control
• Technical verification