Supported cluster types
|Cluster Type||Concierge Works?|
|VMware Tanzu Kubernetes Grid (TKG) clusters||Yes|
|Amazon Elastic Kubernetes Service (EKS)||Yes|
|Google Kubernetes Engine (GKE)||Yes|
|Azure Kubernetes Service (AKS)||Yes|
The Pinniped Concierge has two strategies available to support clusters, under the following conditions:
Token Credential Request API: Can be run on any Kubernetes cluster where a custom pod can be executed on the same node running
kube-controller-manager. This type of cluster is typically called “self-hosted” because the cluster’s control plane is running on nodes that are part of the cluster itself. Most managed Kubernetes services do not support this.
Impersonation Proxy: Can be run on any Kubernetes cluster. Default configuration requires that a
LoadBalancerservice can be created. Most cloud-hosted Kubernetes environments have this capability. The Impersonation Proxy automatically provisions (when
spec.impersonationProxy.modeis set to
LoadBalancerfor ingress to the impersonation endpoint. Users who wish to use the impersonation proxy without an automatically configured
LoadBalancercan do so with an automatically provisioned
ClusterIPor with a Service that they provision themselves. These options can be configured in the spec of the
If a cluster is capable of supporting both strategies, the Pinniped CLI will use the token credential request API strategy by default.
To choose the strategy to use with the concierge, use the
--concierge-mode flag with
pinniped get kubeconfig.
Possible values are
Do not use the command line option
--anonymous-auth=false in the
kube-apiserver CLI for a cluster that does not use the impersonation proxy strategy. This is because the
kube-apiserver blocks unauthenticated access to the TokenCredentialRequest API of the Concierge, which will prevent users from being able to authenticate.
This does not matter while using the impersonation proxy strategy, which will allow these TokenCredentialRequests requests anyway.