diff --git a/site/content/docs/reference/supported-clusters.md b/site/content/docs/reference/supported-clusters.md
index 28ba554b1..bb1162afc 100644
--- a/site/content/docs/reference/supported-clusters.md
+++ b/site/content/docs/reference/supported-clusters.md
@@ -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.