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

Add description of impersonation proxy strategy to docs

Browse Source
This commit is contained in:
Margo Crawford 2021-03-16 10:24:01 -07:00
parent 3e50b4e129
commit 6ff3e42602
2 changed files with 16 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
site/content/docs/background/architecture.md
View File

@ -1,3 +1,4 @@
---
title: Architecture
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 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
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
will use that instead of using the cluster's signing keypair.)
More cluster integration strategies are coming soon, which will allow Pinniped to
support more Kubernetes cluster types.
* Impersonation Proxy: Pinniped hosts an [impersonation](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation)
proxy that performs actions on behalf of the end user. The impersonation proxy accepts and modifies user requests before passing them through to the
Kubernetes API server.
## kubectl Integration

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

@ -15,15 +15,20 @@ menu:
| [VMware Tanzu Kubernetes Grid (TKG) clusters](https://tanzu.vmware.com/kubernetes-grid) | Yes |
| [Kind clusters](https://kind.sigs.k8s.io/) | Yes |
| [Kubeadm-based clusters](https://kubernetes.io/docs/reference/setup-tools/kubeadm/) | Yes |
| [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/) | No |
| [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine) | No |
| [Azure Kubernetes Service (AKS)](https://azure.microsoft.com/en-us/overview/kubernetes-on-azure) | No |
| [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/) | Yes |
| [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) | Yes |
## 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.
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.