Kubernetes

Kubeconfig contexts that authenticate through a rolle session, for EKS, AKS, GKE, and clusters you run yourself.

rolle kube writes kubeconfig contexts that take their credentials from a rolle session. The kubeconfig holds no token: kubectl runs an exec plugin, the plugin asks rolle, and the context stops working when the session stops. Start the session again and the same context works again.

The examples use session names as rolle session list shows them: Acme Prod/AdministratorAccess for an Identity Center role, Contoso Production for an Azure subscription, my-project for a Google Cloud project.

Managed clusters

rolle kube list shows the EKS, AKS, or GKE clusters a started session can reach. rolle kube add writes a context for each cluster you name, or for all of them.

rolle start "Acme Prod/AdministratorAccess"
rolle kube list "Acme Prod/AdministratorAccess"             # NAME  LOCATION  ENDPOINT
rolle kube add "Acme Prod/AdministratorAccess" prod-eu --use # one cluster, made the current context
rolle kube add "Contoso Production" --all                    # every AKS cluster in the subscription
rolle kube add my-project web --context gke-web              # a GKE cluster under another context name
kubectl --context prod-eu get nodes

An EKS session searches its own region. Pass --region to search another one. Without a cluster name and without --all, rolle kube add lists the clusters and exits with code 1, so a script never writes a context by accident.

How each cloud authenticates

EKS. The context runs aws eks get-token with AWS_PROFILE set to the session’s profile. The AWS CLI reads the profile, which fetches credentials through rolle, and signs the token request. The AWS CLI must be installed.

AKS and GKE. The context runs rolle kube token <session>, which prints a short-lived bearer token for the cluster: an Entra ID token for the AKS server application, or the session’s Google Cloud token. The rolle command must be on your PATH; Install command in the desktop app does this.

Clusters you run yourself

A context that already runs an exec plugin on AWS credentials, such as aws-iam-authenticator on a kops or kubeadm cluster, can follow a session too. rolle kube attach sets AWS_PROFILE on that plugin:

rolle kube attach "Acme Prod/AdministratorAccess" kops-prod

For an Azure or Google Cloud session, attach replaces the context’s exec plugin with rolle kube token. Clusters that authenticate with client certificates or their own OIDC provider are out of scope.

Where it writes

rolle kube add and rolle kube attach edit the first file in $KUBECONFIG, else ~/.kube/config, or the file named with --kubeconfig. Entries with the same name are replaced; every other entry and field stays. The context and cluster entries take the cluster name; a context that already exists keeps its namespace. The user entry is rolle:<profile>@<cluster> for AWS, since the token command names the cluster, and rolle:<session> for Azure and Google Cloud.