Cluster credentials scattered across kubeconfig files are a standing privilege problem. Ixiea brokers kubectl exec, port-forward, and API calls through the same policy engine as SSH and RDP.
Operator
IdP identity
K8s connector
Broker path
Cluster
API server
Kubeconfig
Not distributed
RBAC mapped
IdP group → role
No standing cluster-admin kubeconfig. Session grants tied to identity.
Shared cluster-admin kubeconfigs, long-lived service account tokens, and vendor VPN paths into prod clusters are difficult to revoke and nearly impossible to audit command-by-command. Gateways replace standing kubeconfig access with session grants tied to identity.
Kubeconfig sprawl
Shared cluster-admin · vendor VPN · long-lived tokens
Session grants
Identity-bound · revocable · command-level audit
Kubernetes connector
Grant check · MFA · brokered credentials
Cluster API
kubectl · exec · port-forward
Operators authenticate to Ixiea, not directly to the API server. The Kubernetes connector validates grants, applies MFA, and establishes a brokered session using asset account credentials or configured access paths. kubectl, k9s, and web terminals route through the gateway; raw kubeconfig files with cluster-admin are not distributed.
Map IdP groups to Kubernetes permissions at session start. A platform engineer and a vendor support identity receive different effective access even on the same cluster. Permission bindings and session metadata are captured for audit.
IdP groups
view
staging
edit
prod
Effective permissions differ per identity on the same cluster
API calls and exec sessions produce structured logs, resource, verb, namespace, identity, plus optional exec recording for shells inside pods. Evidence exports align with SOC 2 CC6/CC7 without relying on cluster audit logs alone.
Operational docs
Ready to evaluate?
Walk through gateway brokering, recording, and audit exports in a working session — or browse the illustrated product flow first.
