From 7f5bf5d75651ab322b8f9b14079cc343415baf69 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 --- ...25.0-impersonation-proxy-with-external-certs.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) 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..56869c0c 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 @@ -14,7 +14,7 @@ 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) and [Azure Kubernetes Service (AKS)](https://azure.microsoft.com/en-us/overview/kubernetes-on-azure). @@ -48,7 +48,7 @@ $ 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 +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 @@ -64,7 +64,7 @@ $ kubectl get pods \ ``` 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). ```shell @@ -110,7 +110,7 @@ $ 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). @@ -123,7 +123,7 @@ In summary, we will do the following: - 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 +221,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` @@ -367,7 +367,7 @@ 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 +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.