From e5e8c13f23016d5b3179c373a2295787d8d86ce6 Mon Sep 17 00:00:00 2001 From: "Benjamin A. Petersen" Date: Mon, 14 Aug 2023 11:59:23 -0400 Subject: [PATCH] blog: impersonation-proxy spelling, grammar --- .../posts/2021-06-02-first-ldap-release.md | 2 +- ...impersonation-proxy-with-external-certs.md | 51 ++++++++++--------- 2 files changed, 27 insertions(+), 26 deletions(-) diff --git a/site/content/posts/2021-06-02-first-ldap-release.md b/site/content/posts/2021-06-02-first-ldap-release.md index 2f3267ae..ba3eac32 100644 --- a/site/content/posts/2021-06-02-first-ldap-release.md +++ b/site/content/posts/2021-06-02-first-ldap-release.md @@ -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. 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 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 diff --git a/site/content/posts/2023-08-09-v0.25.0-impersonation-proxy-with-external-certs.md b/site/content/posts/2023-08-09-v0.25.0-impersonation-proxy-with-external-certs.md index 726efe42..8bfa8b5a 100644 --- a/site/content/posts/2023-08-09-v0.25.0-impersonation-proxy-with-external-certs.md +++ b/site/content/posts/2023-08-09-v0.25.0-impersonation-proxy-with-external-certs.md @@ -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 date: 2023-08-09 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) *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 -[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). 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. 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 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 -cluster with an Ingress Controller. We will later deploy a Contour HTTPProxy in order to create DNS that we can -use to access the Impersonation Proxy. +cluster with an Ingress Controller. We will later deploy a Contour HTTPProxy to create DNS that we can +use to access the impersonation proxy. ```shell # From https://projectcontour.io/getting-started/ @@ -63,8 +64,8 @@ $ kubectl get pods \ --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 -use, but is sufficient for our needs to exercise the new feature of the impersonation proxy. Install Pinniped’s local-user-authenticator +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 and add some sample users (see https://pinniped.dev/docs/tutorials/concierge-only-demo/ for more details). ```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 -with a real external OIDC Identity Provider. Install Pinniped's Concierge: +with a real external OIDC identity provider. Install Pinniped's Concierge: ```shell $ kubectl apply \ @@ -101,8 +102,8 @@ $ kubectl apply \ --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 generate our CA certificates as well as our TLS serving certificates. Install `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: ```shell $ kubectl apply \ @@ -110,20 +111,20 @@ $ kubectl apply \ --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. -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: - 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 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 `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 - 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 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`. @@ -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. -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: - 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 ``` -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 -`local-user-authenticator` namespace. We previously retrieved the Secret named `local-user-authenticator-tls-serving-certificate` +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 +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 -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 `..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 # 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. `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 $ 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 ``` -Note that using a static-token does embed those credentials into your kubeconfig. This is not suitable for a production -deployment. As we said before, we are using `local-user-authenticator` as a simple Identity Provider for illustrative purposes +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 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 # be sure you added 127.0.0.1 impersonation-proxy-mtls.local to your /etc/hosts!