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 7f5bf5d756
No known key found for this signature in database
GPG Key ID: EF6EF83523A4BE46
1 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -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.