Set up team and CI access

Podplane uses OIDC for both human and service authentication. Your identity provider authenticates the caller and supplies group claims; Kubernetes RBAC decides what those groups may do.

Team access

Assign people to the Podplane groups that match their responsibilities, then have them run:

podplane login -f podplane.cluster.jsonc

After sign-in, Podplane stores the credentials in the user’s keyring and configures kubectl to use them. When a token expires, Podplane refreshes it automatically. Start with the least-privileged role that meets their needs (viewer, editor, operator, manager, or administrator) and grant greater access only when it is needed.

See Role-based Access Control for the exact groups and their Kubernetes permissions.

CI access

Truster can exchange a short-lived GitHub Actions or Buildkite identity for a cluster token. Trust policies should restrict the allowed organisation, repository, branch, pipeline, and resulting groups.

For GitHub Actions, grant the job id-token: write and keep one random keyring password available to each Podplane step:

export PODPLANE_KEYRING_PASS="$(openssl rand -hex 32)"
podplane login --identity-provider github
podplane deploy web --name api --image "$IMAGE"

Store PODPLANE_KEYRING_PASS as an encrypted CI secret when commands run in separate steps, and never print it. Buildkite works the same way with --identity-provider buildkite.

For provider detection, identity files, token renewal, and required OIDC federation support, see the login reference.