Add description of impersonation proxy strategy to docs
This commit is contained in:
parent
3e50b4e129
commit
6ff3e42602
@ -1,3 +1,4 @@
|
|||||||
|
|
||||||
---
|
---
|
||||||
title: Architecture
|
title: Architecture
|
||||||
description: Dive into the overall design and implementation details of Pinniped.
|
description: Dive into the overall design and implementation details of Pinniped.
|
||||||
@ -90,14 +91,14 @@ cleanly enable this integration.
|
|||||||
|
|
||||||
Pinniped supports the following cluster integration strategies.
|
Pinniped supports the following cluster integration strategies.
|
||||||
|
|
||||||
* Pinniped hosts a credential exchange API endpoint via a Kubernetes aggregated API server.
|
* Kube Cluster Signing Certificate: Pinniped hosts a credential exchange API endpoint via a Kubernetes aggregated API server.
|
||||||
This API returns a new cluster-specific credential using the cluster's signing keypair to
|
This API returns a new cluster-specific credential using the cluster's signing keypair to
|
||||||
issue short-lived cluster certificates. (In the future, when the Kubernetes CSR API
|
issue short-lived cluster certificates. (In the future, when the Kubernetes CSR API
|
||||||
provides a way to issue short-lived certificates, then the Pinniped credential exchange API
|
provides a way to issue short-lived certificates, then the Pinniped credential exchange API
|
||||||
will use that instead of using the cluster's signing keypair.)
|
will use that instead of using the cluster's signing keypair.)
|
||||||
|
* Impersonation Proxy: Pinniped hosts an [impersonation](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation)
|
||||||
More cluster integration strategies are coming soon, which will allow Pinniped to
|
proxy that performs actions on behalf of the end user. The impersonation proxy accepts and modifies user requests before passing them through to the
|
||||||
support more Kubernetes cluster types.
|
Kubernetes API server.
|
||||||
|
|
||||||
## kubectl Integration
|
## kubectl Integration
|
||||||
|
|
||||||
|
@ -15,15 +15,20 @@ menu:
|
|||||||
| [VMware Tanzu Kubernetes Grid (TKG) clusters](https://tanzu.vmware.com/kubernetes-grid) | Yes |
|
| [VMware Tanzu Kubernetes Grid (TKG) clusters](https://tanzu.vmware.com/kubernetes-grid) | Yes |
|
||||||
| [Kind clusters](https://kind.sigs.k8s.io/) | Yes |
|
| [Kind clusters](https://kind.sigs.k8s.io/) | Yes |
|
||||||
| [Kubeadm-based clusters](https://kubernetes.io/docs/reference/setup-tools/kubeadm/) | Yes |
|
| [Kubeadm-based clusters](https://kubernetes.io/docs/reference/setup-tools/kubeadm/) | Yes |
|
||||||
| [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/) | No |
|
| [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/) | Yes |
|
||||||
| [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine) | No |
|
| [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine) | Yes |
|
||||||
| [Azure Kubernetes Service (AKS)](https://azure.microsoft.com/en-us/overview/kubernetes-on-azure) | No |
|
| [Azure Kubernetes Service (AKS)](https://azure.microsoft.com/en-us/overview/kubernetes-on-azure) | Yes |
|
||||||
|
|
||||||
## Background
|
## Background
|
||||||
|
|
||||||
The Pinniped Concierge currently supports clusters where a custom pod can be executed on the same node running `kube-controller-manager`.
|
The Pinniped Concierge has two strategies available to support clusters, under the following conditions:
|
||||||
|
|
||||||
|
1. Kube Cluster Signing Certificate: 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.
|
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.
|
||||||
|
|
||||||
In practice, this means that many Kubernetes distributions are supported, but not most managed Kubernetes services
|
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.
|
||||||
|
|
||||||
Support for more cluster types, including managed Kubernetes environments, is planned.
|
If a cluster is capable of supporting both strategies, the Pinniped Concierge will use the
|
||||||
|
kube cluster signing certificate strategy.
|
||||||
|
Loading…
Reference in New Issue
Block a user