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

blog: impersonation-proxy spelling, grammar

Browse Source
This commit is contained in:
Benjamin A. Petersen 2023-08-14 11:59:23 -04:00
parent b81206c15d
commit e5e8c13f23
No known key found for this signature in database
GPG Key ID: EF6EF83523A4BE46
2 changed files with 27 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
site/content/posts/2021-06-02-first-ldap-release.md
View File

@ -118,7 +118,7 @@ We've provided examples of using [OpenLDAP]({{< ref "docs/howto/install-supervis
and [JumpCloud]({{< ref "docs/howto/install-supervisor.md" >}}) as LDAP providers. and [JumpCloud]({{< ref "docs/howto/install-supervisor.md" >}}) as LDAP providers.
Stay tuned for examples of using Active Directory. Stay tuned for examples of using Active Directory.
The `pinniped` CLI has also been enhanced to support LDAP authentication. Now when `pinnped get kubectl` sees The `pinniped` CLI has also been enhanced to support LDAP authentication. Now when `pinniped get kubectl` sees
that your cluster's Concierge is configured to use a Supervisor which has an LDAPIdentityProvider, then it that your cluster's Concierge is configured to use a Supervisor which has an LDAPIdentityProvider, then it
will emit the appropriate kubeconfig to enable LDAP logins. When that kubeconfig is used with `kubectl`, will emit the appropriate kubeconfig to enable LDAP logins. When that kubeconfig is used with `kubectl`,
the Pinniped plugin will directly prompt the user on the CLI for their LDAP username and password and the Pinniped plugin will directly prompt the user on the CLI for their LDAP username and password and

51
site/content/posts/2023-08-09-v0.25.0-impersonation-proxy-with-external-certs.md
View File

@ -1,5 +1,5 @@
--- ---
title: "Pinniped v0.25.0: With External Certificate Management for the Impersonation Proxy and more" title: "Pinniped v0.25.0: With External Certificate Management for the Impersonation Proxy and more!"
slug: v0-25-0-external-cert-mgmt-impersonation-proxy slug: v0-25-0-external-cert-mgmt-impersonation-proxy
date: 2023-08-09 date: 2023-08-09
author: Joshua T. Casey author: Joshua T. Casey
@ -14,9 +14,9 @@ tags: ['Joshua T. Casey','Ryan Richard', 'Benjamin Petersen', 'release', 'kubern
![Friendly seal](https://images.unsplash.com/photo-1618075254460-429d47b887c7?ixlib=rb-4.0.3&ixid=M3wxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8fA%3D%3D&auto=format&fit=crop&w=2148&q=80) ![Friendly seal](https://images.unsplash.com/photo-1618075254460-429d47b887c7?ixlib=rb-4.0.3&ixid=M3wxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8fA%3D%3D&auto=format&fit=crop&w=2148&q=80)
*Photo by [karlheinz_eckhardt Eckhardt](https://unsplash.com/@karlheinz_eckhardt) on [Unsplash](https://unsplash.com/s/photos/seal)* *Photo by [karlheinz_eckhardt Eckhardt](https://unsplash.com/@karlheinz_eckhardt) on [Unsplash](https://unsplash.com/s/photos/seal)*
With Pinniped v0.25.0 you get the ability to configure an externally-generated certificate for Pinnniped Concierge's impersonation proxy to serve TLS. The With Pinniped v0.25.0 you get the ability to configure an externally-generated certificate for Pinniped Concierge's impersonation proxy to serve TLS. The
impersonation proxy is a component within Pinniped that allows the project to support many types of clusters, such as impersonation proxy is a component within Pinniped that allows the project to support many types of clusters, such as
[Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/), [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine) [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/), [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine),
and [Azure Kubernetes Service (AKS)](https://azure.microsoft.com/en-us/overview/kubernetes-on-azure). and [Azure Kubernetes Service (AKS)](https://azure.microsoft.com/en-us/overview/kubernetes-on-azure).
To read more on this feature, and the design decisions behind it, see the [proposal](https://github.com/vmware-tanzu/pinniped/tree/main/proposals/1547_impersonation-proxy-external-certs). To read more on this feature, and the design decisions behind it, see the [proposal](https://github.com/vmware-tanzu/pinniped/tree/main/proposals/1547_impersonation-proxy-external-certs).
@ -25,7 +25,8 @@ To read more about the impersonation proxy, see the [docs](https://pinniped.dev/
To see the feature in practice on a local kind cluster, follow these instructions. To see the feature in practice on a local kind cluster, follow these instructions.
This will perform mTLS between your local client (kubectl and the pinniped CLI) and the impersonation proxy. This will perform mTLS between your local client (kubectl and the pinniped CLI) and the impersonation proxy.
The setup: We will be using a kind cluster, Contour as an ingress to the impersonation proxy, and `cert-manager` to generate a TLS serving cert. The setup: We will be using a kind cluster, Contour as an ingress to the impersonation proxy, and cert-manager to generate a TLS serving cert.
The setup: We will be using a kind cluster, Contour as an ingress to the impersonation proxy, and cert-manager to generate a TLS serving cert.
```shell ```shell
Docker desktop v1.20.1 Docker desktop v1.20.1
@ -48,8 +49,8 @@ $ kind create cluster \
``` ```
Now we will install Contour (see https://projectcontour.io/getting-started/ for more details). Contour provides our kind Now we will install Contour (see https://projectcontour.io/getting-started/ for more details). Contour provides our kind
cluster with an Ingress Controller. We will later deploy a Contour HTTPProxy in order to create DNS that we can cluster with an Ingress Controller. We will later deploy a Contour HTTPProxy to create DNS that we can
use to access the Impersonation Proxy. use to access the impersonation proxy.
```shell ```shell
# From https://projectcontour.io/getting-started/ # From https://projectcontour.io/getting-started/
@ -63,8 +64,8 @@ $ kubectl get pods \
--kubeconfig kind-with-contour.kubeconfig.yaml --kubeconfig kind-with-contour.kubeconfig.yaml
``` ```
Pinniped's local-user-authenticator will act as a dummy Identity Provider for our example. This resource is not for production Pinniped's local-user-authenticator will act as a dummy identity provider for our example. This resource is not for production
use, but is sufficient for our needs to exercise the new feature of the impersonation proxy. Install Pinniped’s local-user-authenticator use but is sufficient for our needs to exercise the new feature of the impersonation proxy. Install Pinniped’s local-user-authenticator
and add some sample users (see https://pinniped.dev/docs/tutorials/concierge-only-demo/ for more details). and add some sample users (see https://pinniped.dev/docs/tutorials/concierge-only-demo/ for more details).
```shell ```shell
@ -89,7 +90,7 @@ $ kubectl get secret local-user-authenticator-tls-serving-certificate \
``` ```
In this example, we are only interacting with the Pinniped's Concierge. The Supervisor is not in use as we are not interacting In this example, we are only interacting with the Pinniped's Concierge. The Supervisor is not in use as we are not interacting
with a real external OIDC Identity Provider. Install Pinniped's Concierge: with a real external OIDC identity provider. Install Pinniped's Concierge:
```shell ```shell
$ kubectl apply \ $ kubectl apply \
@ -101,8 +102,8 @@ $ kubectl apply \
--kubeconfig kind-with-contour.kubeconfig.yaml --kubeconfig kind-with-contour.kubeconfig.yaml
``` ```
To handle X.509 certificate management for us, we will install cert-manager. For the purposes of this exercise, we will use `cert-manager` To handle X.509 certificate management for us, we will install cert-manager. For the purposes of this exercise, we will use cert-manager
to generate our CA certificates as well as our TLS serving certificates. Install `cert-manager`: to generate our CA certificates as well as our TLS serving certificates. Install cert-manager:
```shell ```shell
$ kubectl apply \ $ kubectl apply \
@ -110,20 +111,20 @@ $ kubectl apply \
--kubeconfig kind-with-contour.kubeconfig.yaml --kubeconfig kind-with-contour.kubeconfig.yaml
``` ```
For this demonstration we will be using `cert-manager` to simulate our own Public Key Infrastructure (PKI). For this demonstration, we will be using cert-manager to simulate our own Public Key Infrastructure (PKI).
We will create the appropriate CA certificates and TLS serving certificates for the impersonation proxy to serve TLS. We will create the appropriate CA certificates and TLS serving certificates for the impersonation proxy to serve TLS.
For more information about using `cert-manager` to achieve this, see the [cert-manager docs](https://cert-manager.io/docs/configuration/selfsigned/#bootstrapping-ca-issuers). For more information about using cert-manager to achieve this, see the [cert-manager docs](https://cert-manager.io/docs/configuration/selfsigned/#bootstrapping-ca-issuers).
In summary, we will do the following: In summary, we will do the following:
- Create two `ClusterIssuer` resources, one named `selfsigned-cluster-issuer` and another named `my-ca-issuer`. - Create two `ClusterIssuer` resources, one named `selfsigned-cluster-issuer` and another named `my-ca-issuer`.
- The `ClusterIssuer` named `my-ca-issuer` will be used to create several `Certificat`e resources. First, we will create - The `ClusterIssuer` named `my-ca-issuer` will be used to create several `Certificate` resources. First, we will create
the `Certificate` called `my-selfsigned-ca` (which will reference a `Secret` named `self-signed-ca-for-kind-testing` where the `Certificate` called `my-selfsigned-ca` (which will reference a `Secret` named `self-signed-ca-for-kind-testing` where
the actual certificate data will be stored). the actual certificate data will be stored).
- We will later retrieve the `Secret` called `self-signed-ca-for-kind-testing` so that we can add the CA to the Pinniped Concierge's - We will later retrieve the `Secret` called `self-signed-ca-for-kind-testing` so that we can add the CA to the Pinniped Concierge's
`CredentialIssuer` resource so that it can be advertised and used to verify TLS serving certificates. `CredentialIssuer` resource so that it can be advertised and used to verify TLS serving certificates.
- Then, we will create the `ClusterIssuer` called `my-ca-issuer`. We will reference the `Certificate` called `my-selfsigned-ca` via - Then, we will create the `ClusterIssuer` called `my-ca-issuer`. We will reference the `Certificate` called `my-selfsigned-ca` via
it's `Secret` named `self-signed-ca-for-kind-testing`. This will allow us to use the CA to sign TLS serving certificates. its `Secret` named `self-signed-ca-for-kind-testing`. This will allow us to use the CA to sign TLS serving certificates.
- Then, we will use the `ClusterIssuer` called `my-ca-issuer` to generate a `Certificate` that will be a TLS serving certificate - Then, we will use the `ClusterIssuer` called `my-ca-issuer` to generate a `Certificate` that will be a TLS serving certificate
called `impersonation-serving-cert`. As before, the actual certificate data will be stored in a Kubernetes `Secret` which we called `impersonation-serving-cert`. As before, the actual certificate data will be stored in a Kubernetes `Secret` which we
will name `impersonation-proxy-tls-serving-cert`. will name `impersonation-proxy-tls-serving-cert`.
@ -221,7 +222,7 @@ $ kubectl get secret self-signed-ca-for-kind-testing \
``` ```
The `CredentialIssuer` resource called `pinniped-concierge-config` already exists. We need to edit it. The `CredentialIssuer` resource called `pinniped-concierge-config` already exists. We need to edit it.
Kind clusters have no need to use the impersonation proxy by default (it is designed for public cloud providers), Kind clusters do not need to use the impersonation proxy by default (it is designed for public cloud providers),
so we will make several changes to this resource: so we will make several changes to this resource:
- Set the `spec.impersonationProxy.mode: enabled` - Set the `spec.impersonationProxy.mode: enabled`
@ -294,14 +295,14 @@ $ kubectl get service pinniped-concierge-impersonation-proxy-cluster-ip \
--kubeconfig kind-with-contour.kubeconfig.yaml --kubeconfig kind-with-contour.kubeconfig.yaml
``` ```
Configure a webhook authenticator to tell Concierge to validate static tokens using the installed `local-user-authenticator`. Configure a webhook authenticator to tell Concierge to validate static tokens using the installed local-user-authenticator.
When we installed the Pinniped `local-user-authenticator`, we created a service called `local-user-authenticator` in the When we installed the Pinniped local-user-authenticator, we created a service called local-user-authenticator in the
`local-user-authenticator` namespace. We previously retrieved the Secret named `local-user-authenticator-tls-serving-certificate` local-user-authenticator namespace. We previously retrieved the Secret named `local-user-authenticator-tls-serving-certificate`
so that we could use it to configure this `WebhookAuthenticator` to use that certificate. Note that we did not generate this so that we could use it to configure this `WebhookAuthenticator` to use that certificate. Note that we did not generate this
certificate via `cert-manager`, this is still a self-signed certificate created by Pinniped. certificate via cert-manager, this is still a self-signed certificate created by Pinniped.
The `endpoint` here is referenced via Kubernetes DNS in the format `<namespace>.<service-name>.svc` targeting the `/authenticate` The `endpoint` here is referenced via Kubernetes DNS in the format `<namespace>.<service-name>.svc` targeting the `/authenticate`
endpoint of the `local-user-authenticator`. We will be using https, if course. endpoint of the local-user-authenticator. We will be using https, if course.
```yaml ```yaml
# Configure a webhook authenticator to tell Concierge to validate static tokens using the installed local-user-authenticator # Configure a webhook authenticator to tell Concierge to validate static tokens using the installed local-user-authenticator
@ -330,7 +331,7 @@ with the impersonation proxy, and so that client certs used for mTLS will be sen
Note in particular the `spec.tcpproxy` block, which is different than the typical `spec.rules` block. Note in particular the `spec.tcpproxy` block, which is different than the typical `spec.rules` block.
`spec.tcpproxy` is required when using `spec.virtualhost.tls.passthrough: true`. `spec.tcpproxy` is required when using `spec.virtualhost.tls.passthrough: true`.
See https://projectcontour.io/docs/1.25/config/tls-termination/#tls-session-passthrough for more details. See [contour docs for tls session passthrough](https://projectcontour.io/docs/1.25/config/tls-termination/#tls-session-passthrough) for more details.
```shell ```shell
$ cat << EOF > contour-ingress-impersonation-proxy.yaml $ cat << EOF > contour-ingress-impersonation-proxy.yaml
@ -367,10 +368,10 @@ In this example, we will edit the `/etc/hosts` file to resolve the `impersonatio
127.0.0.1 impersonation-proxy-mtls.local 127.0.0.1 impersonation-proxy-mtls.local
``` ```
Note that using a static-token does embed those credentials into your kubeconfig. This is not suitable for a production Note that using a static-token does embed those credentials into your kubeconfig. This is not suitable for production
deployment. As we said before, we are using `local-user-authenticator` as a simple Identity Provider for illustrative purposes deployment. As we said before, we are using local-user-authenticator as a simple identity provider for illustrative purposes
only. In a real production use case you would not employ the `--static-token` flag which would ensure credentials are not only. In a real production use case you would not employ the `--static-token` flag which would ensure credentials are not
embedded in your kubeconfig, an important security feature. Never use `local-user-authenticator` in production. embedded in your kubeconfig, an important security feature. Never use local-user-authenticator in production.
```shell ```shell
# be sure you added 127.0.0.1 impersonation-proxy-mtls.local to your /etc/hosts! # be sure you added 127.0.0.1 impersonation-proxy-mtls.local to your /etc/hosts!