Access, kubectl, and identity

This page explains how you and your teammates actually use a Kubernetes workspace: credentials, authentication modes, and permission concepts — not HTTP endpoints.

Two kubeconfig flavors

Loopback exposes two different kubeconfig experiences for the same underlying cluster:

1. Admin kubeconfig (break-glass)

What it is
A kubeconfig that uses the super-admin credentials Loopback extracted when the cluster was born — equivalent to full cluster administration.

When to use it

Initial bootstrap of GitOps, emergency break-glass, or automation that must not depend on interactive login.
Situations where your corporate IdP is unavailable but operations must continue (use sparingly).

Operational risk
Anyone with download permission can exfiltrate long-lived root access. Treat this like root SSH keys: rotate by reprovisioning or support processes, store in a vault, and restrict RBAC tightly.

How you obtain it
Through any client that performs the same permission checks as the product’s “download admin kubeconfig” capability (internally gated behind a kubeconfig-specific read permission distinct from general workspace read).

You can usually choose YAML or JSON representation for tooling.

2. OIDC kubeconfig (day-to-day)

What it is
A kubeconfig whose user entry runs kubectl as an exec plugin that performs OIDC login against the issuer Loopback configured for the platform.

Concretely, the generated kubeconfig uses:

kubectl itself as the command.
Arguments compatible with kubectl oidc-login get-token (plugin), including:
- OIDC issuer URL (from operator configuration).
- Client id equal to your workspace id (stable per workspace).
- Client secret stored with the workspace authorization record.
- Scopes for profile and email.
- Local listen addresses for the login callback.

When to use it

Developers and SREs doing normal work.
Compliance regimes that forbid shared long-lived admin keys.

What your IdP must do
Your identity provider must issue tokens acceptable to the API server’s OIDC configuration (groups claim, email claim, etc.). The cluster’s API server was bootstrapped with flags such as username claim = email and groups claim = groups in the Kamaji manifest template.

Permission note
Retrieving the OIDC kubeconfig is typically gated behind an “authenticate” style permission — slightly different from admin kubeconfig — so you can let developers log in without handing them break-glass files.

OIDC session settings

The workspace model carries OIDC-oriented authorization settings including:

Whether OIDC login is enabled for the cluster (operator and workspace state dependent).
Session expiration seconds for interactive sessions (used for policy and UX expectations).

If OIDC is disabled for a workspace, rely on admin kubeconfig or ask your operator to re-enable OIDC integration.

Workspace API key vs kubeconfig

Every workspace receives a workspace API key.

It is not a Kubernetes token.
It is used when Loopback components or in-cluster integrations need to call Loopback’s own HTTP APIs on behalf of that workspace (for example load balancer automation that stores a secret in loopback-ccm).

You normally do not paste the workspace API key into kubectl. Use kubeconfigs instead.

Kubernetes API proxy features

Some product surfaces let you perform Kubernetes API operations through Loopback using server-side kubeconfig material — useful for constrained clients or audited actions. Those flows still enforce project/workspace RBAC before they touch the cluster.

Treat them as convenience wrappers around the same RBAC you would hit with kubectl directly.

RBAC inside your cluster

During provisioning Loopback creates a ClusterRoleBinding that maps the OIDC group loopback-workspace-claim to cluster-admin.

Practical effect

Users whose IdP tokens include that group (or who map through your IdP configuration) land as cluster administrators.
Fine-grained Kubernetes RBAC can still be layered by your manifests once you adopt GitOps.

Security guidance

Control membership of loopback-workspace-claim in your IdP as carefully as membership in a production admin group.
Prefer namespace-scoped roles for application teams where possible.

Choosing compute providers before creation

Inside a project you can usually list which compute provider types are available for new Kubernetes workspaces — derived from which Kamaji management pools the operator activated.

You can also list Kubernetes versions offered for new workspaces; that list is not identical to “versions you may upgrade to later” (upgrades consult a separate compatibility matrix).