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

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
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 `<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
# 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!