Kubernetes Clusters
Provision a new cluster (AWS EKS, Azure AKS, or
GCP GKE) or register a reachable one from its kubeconfig, then broker access —
a native PRA tunnel for raw kubectl and Entra-federated
real-identity JIT. The kubeconfig is stored as a secrets-backend reference, never shown back.
| Name | Cloud | Region | Workstream | Status | Management | API server | Actions |
|---|---|---|---|---|---|---|---|
| prov | – |
|
Workstream
Everyone in the chosen workstream can see and manage — including its cluster-admin kubeconfig, brokered access, and its auto-delete timer. Clearing the workstream returns it to its creator.
Register Kubernetes cluster
From a discovery scan: . Paste a kubeconfig whose server: matches it — the agent identified the cluster but never authenticated to it.
Stored as a secrets-backend reference; the API server is parsed from it.
Everyone in this workstream can see and manage this cluster — its kubeconfig is cluster-admin, so this is a real grant. Leave blank and only you and administrators can.
Provision Kubernetes cluster
Stands up a managed cluster with Terraform, stores its kubeconfig as a secrets-backend reference, and registers it — then launch a plane / broker access / install secrets as usual. EKS, AKS, and GKE are supported; OKE is experimental (no Entra federation, in-process kubectl, not yet live-validated). Every cluster builds its own network with internet egress — no shared sandbox subnets; EKS additionally peers its VPC back to the sandbox so in-cluster agents can reach the private VMs/DBs directly.
Everyone in this workstream can see and manage this cluster. Its kubeconfig is cluster-admin, so this is a real grant.
EC2 type / AKS vm_size / GKE machine type. Blank = module default.
Zonal cluster (cheaper than regional). Blank uses the region's configured zone (Settings → Multi-region), else the region's first available zone.
Restricts the public API endpoint. Blank = open (0.0.0.0/0). The dashboard runner must be able to reach it.
Blank = default 10.97.0.0/16. Must not overlap the sandbox VPC (10.99.0.0/16); give each concurrent cluster a distinct block.
Blank = default 10.96.0.0/16. Must not overlap the sandbox VCN (10.98.0.0/16); give each concurrent cluster a distinct block.
Provisioning takes ~5–15 min; the row shows provisioning → registered. AKS/GKE nodes get internet egress (managed outbound / Cloud NAT) so an installed Entitle agent can reach its SaaS.
Broker access —
When PRA is configured this provisions a native tunnel_type=k8s jump (via the beyondtrust/sra provider)
and brokers a session with no public ingress. These per-cluster overrides fall back to the configured defaults.
Resolved to a bt_client_secret override for this cluster's tunnel provisioning.
PRA tunnel —
Provisions a native tunnel_type=k8s jump (via the beyondtrust/sra provider) to this
cluster's API server, so you reach it with raw kubectl through the PRA representative console — no
public ingress. These per-cluster overrides fall back to the configured defaults.
PRA is not configured (bt_api_host / bt_client_id / bt_client_secret). Set it on Settings — the dropdowns stay empty and provisioning will fail until then.
Resolved to a bt_client_secret override for this cluster's tunnel provisioning.
Direct API tunnel —
Provisions a generic tunnel_type=tcp jump straight to this cluster's API server and gives
you a token-free kubeconfig that logs in with your own cloud-CLI identity — so
kubectl --as impersonation works for Entitle grants (the tunnel_type=k8s
tunnel injects a fixed token and blocks impersonation). These overrides fall back to the configured defaults.
Prereq: the cloud CLI + auth plugin (gke-gcloud-auth-plugin / aws /
kubelogin) installed and logged in as an identity with cluster RBAC; impersonating
Entitle grants needs that identity to be cluster-admin.
PRA is not configured (bt_api_host / bt_client_id / bt_client_secret). Set it on Settings — the dropdowns stay empty and provisioning will fail until then.
Resolved to a bt_client_secret override for this cluster's tunnel provisioning.
Tunnel provisioned. Connect the Jump Item in the PRA representative console, then download this kubeconfig and point KUBECONFIG at it.
group → cluster RBAC —
Binds an group to a ClusterRole on this cluster. Any member gets
that role when they sign in as themselves (their token's group matches the RBAC subject) —
so Entitle's directory integration JIT-grants real-identity access, no impersonation and no synthetic
subject. Leave a field blank to use the default configured on Settings → Kubernetes.
On EKS the subject is ,
matching the groups prefix the federation sets.
Run Kubernetes work on —
Config Management plays against this cluster can run on a deployed agent in its cloud instead of the remote worker: no cold start, and no dashboard worker slot. The agent receives this cluster's cluster-admin kubeconfig, sealed to it for one job, so only an agent this dashboard deployed qualifies — SPIRE-attested, agent 2.13 or later, with Allow Kubernetes work on its host. While it is offline, work runs on the remote worker.
:
:
No agent is deployed in this cluster's cloud. Deploy one from Remote Agents → Agents.
Impersonation access —
Grants the IdP group cluster-wide impersonate on users (never groups —
system:masters stays blocked). This is the fine-grained tier: a group member authenticates as
themselves and can impersonate, but has nothing to impersonate as until Entitle's
Kubernetes integration JIT-binds <prefix>:<email> → a role on
this cluster. They then run kubectl --as=<prefix>:<email> over the
API tunnel (never the k8s tunnel — that proxy strips impersonation headers; on GKE with a
workforce identity it's Connect Gateway, which does forward them). Reuses the IdP group
configured on Settings → Kubernetes; leave blank for that default.
On GKE this also grants Cloud IAM — GKE gates impersonate in Cloud IAM as well as
RBAC, so the group's principalSet is bound to a project custom role holding only
container.clusters.impersonate (needs roles/iam.roleAdmin on the dashboard SA).
Allow 1–2 min for IAM to propagate — a --as before then is still
Forbidden and looks exactly like a missing grant. The binding is project-wide, so removing it here
is ref-counted against other GKE clusters using the same group.
The subject is not the raw email — Entitle sanitizes it when it creates the binding
(a.b@corp.com → <prefix>:a.b-corp.com) even though the credential it shows the
user keeps the @. Impersonating the raw email hits an identity with no bindings. Read the exact
subject off the cluster: kubectl get clusterrolebinding -o custom-columns=NAME:.metadata.name,ROLE:.roleRef.name,SUBJECT:.subjects[*].name
(Entitle's are entk8s-*).
federation —
AKS is natively Entra-integrated — the control plane already trusts Entra tokens,
so no federation step is needed. Bind an Entra group, connect the API tunnel,
and download the Entra kubeconfig to sign in as yourself with kubelogin.
AKS trusts only Entra ID, whichever IdP Settings choose for EKS and GKE.
Associates the app (Settings → Kubernetes → Cluster federation IdP) as this EKS cluster's OIDC identity provider, so a user's own token authenticates and its groups match the group RBAC binding — real-identity JIT, no impersonation. EKS makes the association ACTIVE over a few minutes (the job polls). Additive to IAM — node bootstrap and console access are unchanged.
End users need the int128 kubectl oidc-login plugin — install with kubectl krew install oidc-login
(krew registers the kubectl-oidc_login alias reliably; a plain winget/zip install may not). Connect the API
tunnel, then use the downloaded kubeconfig — by default it uses device-code sign-in, so it also works on
domain-joined / cross-tenant machines. EKS allows one OIDC provider per cluster: to move a federated
cluster to another IdP, disable federation first.
GKE uses Workforce Identity Federation + Connect Gateway (not the API tunnel).
Enabling registers this cluster to the fleet, turns on Connect Gateway, and grants your
group's principalSet the
gkehub.gateway IAM roles. Bind the
group too — its RBAC subject on GKE is the workforce principalSet. Set the pool
(whose OIDC provider is this IdP) on Settings → Kubernetes.
End users reach the cluster through Connect Gateway (no tunnel). Sign in as your federated workforce identity first, then use the downloaded kubeconfig:
gcloud iam workforce-pools create-login-config \ locations/global/workforcePools/<pool>/providers/<provider> \ --output-file=login.json gcloud auth login --login-config=login.json
Real-identity kubeconfig (token-free; authenticates as your identity over the API tunnel):
Connect Gateway kubeconfig (token-free; authenticates as your workforce identity — run the gcloud auth login above first):
In-cluster secret delivery —
Choose where in-cluster workloads get their secrets. The dashboard installs BeyondTrust's own integration — it never proxies the secrets. Current: .
ESO installs as a Helm release + a BeyondTrust ClusterSecretStore authenticated with the configured Password Safe OAuth client (pscli_*). Secrets-Agent is a later option. Enable etcd encryption-at-rest where ESO runs.
Password Safe token rotation —
Onboards the PRA-injected ServiceAccount token (pra-access/pra-access) as a Password Safe managed account on the Kubernetes Service Account Token plugin and applies the in-cluster rotator RBAC. The PRA Vault copy is registered on the PRA Vault Token plugin and synced to it in Password Safe, so every rotation reaches PRA and the k8s tunnel keeps working. The functional account must already exist in Password Safe — see the token rotation guide for the plugin import, functional accounts and access policy.
Managed account id: PRA Vault account id:
Reading the sync state from Password Safe…
Synced in Password Safe: — Password Safe pushes every rotation into PRA
Token last changed: next
PRA copy last changed:
The PRA Vault account is not synced to the token account, so rotations will NOT reach PRA. Use Repair registration below — it creates the PRA Vault Token account if it is missing, links the pair, and touches nothing in the cluster. If it fails with a permission error, grant the API identity Password Safe Account Management (Full control) and try again.
Nothing has ever put a real credential in the vault — a ServiceAccount token is too long to seed, so only a completed rotation does, and none has completed. Password Safe is holding the placeholder the account was created with, which authenticates to nothing, and the PRA tunnel would be handed that. Use Repair registration: it re-applies the rotator RBAC (on AKS that is the Azure role assignment, which is what a first rotation refused for "User does not have access to the resource in Azure" was missing) and rotates to fill the vault.
Registration seeds Password Safe with the live token, syncs the PRA Vault account to it, rotates once to prove the path, then deletes the dashboard-minted Secret (the plugin's sweep never touches it). From then on Password Safe delivers every rotation to PRA on its own.