Merge pull request #857 from vmware-tanzu/impersonation-proxy-supported-clusters
Change description of impersonation proxy strategy in supported clusters
This commit is contained in:
commit
a2cafb251a
@ -27,8 +27,10 @@ The Pinniped Concierge has two strategies available to support clusters, under t
|
||||
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.
|
||||
|
||||
2. Impersonation Proxy: Can be run on any Kubernetes cluster where a `LoadBalancer` service can be created. Most cloud-hosted Kubernetes environments have this
|
||||
capability. The Impersonation Proxy automatically provisions a `LoadBalancer` for ingress to the impersonation endpoint.
|
||||
2. Impersonation Proxy: Can be run on any Kubernetes cluster. Default configuration requires that a `LoadBalancer` service can be created. Most cloud-hosted Kubernetes environments have this
|
||||
capability. The Impersonation Proxy automatically provisions (when `spec.impersonationProxy.mode` is set to `auto`) a `LoadBalancer` for ingress to the impersonation endpoint. Users who wish to use the impersonation proxy without an automatically
|
||||
configured `LoadBalancer` can do so with an automatically provisioned `ClusterIP` or with a Service that they provision themselves. These options
|
||||
can be configured in the spec of the [`CredentialIssuer`](https://github.com/vmware-tanzu/pinniped/blob/main/generated/1.20/README.adoc#credentialissuer).
|
||||
|
||||
If a cluster is capable of supporting both strategies, the Pinniped CLI will use the
|
||||
token credential request API strategy by default.
|
||||
|
Loading…
Reference in New Issue
Block a user