djpbessems/ContainerImage.Pinniped
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge pull request #857 from vmware-tanzu/impersonation-proxy-supported-clusters

Browse Source 
Change description of impersonation proxy strategy in supported clusters
This commit is contained in:
Margo Crawford 2021-10-06 11:40:24 -07:00 committed by GitHub
commit a2cafb251a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 4 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
site/content/docs/reference/supported-clusters.md
View File

@ -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. 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. 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 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 a `LoadBalancer` for ingress to the impersonation endpoint. 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 If a cluster is capable of supporting both strategies, the Pinniped CLI will use the
token credential request API strategy by default. token credential request API strategy by default.