Merge pull request #1631 from vmware-tanzu/which_service_doc
Update docs to clarify which Supervisor port to expose outside cluster
This commit is contained in:
commit
20cfa0a207
@ -5,7 +5,7 @@ cascade:
|
|||||||
layout: docs
|
layout: docs
|
||||||
menu:
|
menu:
|
||||||
docs:
|
docs:
|
||||||
name: As an OIDC Issuer
|
name: Required Configuration
|
||||||
weight: 10
|
weight: 10
|
||||||
parent: howto-configure-supervisor
|
parent: howto-configure-supervisor
|
||||||
aliases:
|
aliases:
|
||||||
@ -22,6 +22,36 @@ This guide explains how to expose the Supervisor's REST endpoints to clients.
|
|||||||
|
|
||||||
This how-to guide assumes that you have already [installed the Pinniped Supervisor]({{< ref "install-supervisor" >}}).
|
This how-to guide assumes that you have already [installed the Pinniped Supervisor]({{< ref "install-supervisor" >}}).
|
||||||
|
|
||||||
|
## Summary
|
||||||
|
|
||||||
|
When the Pinniped Supervisor is installed using the YAML files which are attached to the
|
||||||
|
[GitHub releases](https://github.com/vmware-tanzu/pinniped/releases), then the following additional configuration
|
||||||
|
is required before your end users can use the Supervisor:
|
||||||
|
|
||||||
|
1. You must create a new Service to expose port 8443 of the Supervisor pods, and you must configure your preferred
|
||||||
|
means of HTTPS ingress to allow the Supervisor to receive traffic from outside the cluster.
|
||||||
|
|
||||||
|
This is not included in the YAML files attached to the GitHub releases because there are many ways to control
|
||||||
|
HTTPS traffic in Kubernetes clusters. By allowing you to configure this yourself, you can take advantage of your
|
||||||
|
preferred solution.
|
||||||
|
|
||||||
|
2. You must configure the Supervisor to act as an OIDC provider by creating a FederationDomain resource.
|
||||||
|
You must also create a TLS certificate for the Supervisor to use while serving these requests,
|
||||||
|
and place it in a Secret for the Supervisor to read.
|
||||||
|
|
||||||
|
This is also not included in the YAML files attached to the GitHub releases because there are many ways to
|
||||||
|
create and manage TLS certificates and certificate authorities (CAs).
|
||||||
|
|
||||||
|
These steps are explained in detail in this guide.
|
||||||
|
|
||||||
|
If you would like to see a full working example of configuring the Supervisor,
|
||||||
|
please refer to the sections regarding configuring the Supervisor within other tutorial:
|
||||||
|
- [Concierge with Supervisor: a complete example of every step, demonstrated using GKE clusters]({{< ref "concierge-and-supervisor-demo" >}})
|
||||||
|
|
||||||
|
If you are using a different way to install Pinniped, such as 3rd party Helm Charts or the Pinniped that is
|
||||||
|
integrated into VMware's TKG product, then that method of installation may already include an opinionated
|
||||||
|
ingress and TLS configuration. In that case, please refer to the documentation for your method of installation.
|
||||||
|
|
||||||
## Exposing the Supervisor app's endpoints outside the cluster
|
## Exposing the Supervisor app's endpoints outside the cluster
|
||||||
|
|
||||||
The Supervisor app's endpoints should be exposed as HTTPS endpoints with proper TLS certificates signed by a
|
The Supervisor app's endpoints should be exposed as HTTPS endpoints with proper TLS certificates signed by a
|
||||||
@ -44,15 +74,20 @@ outside the pod may be re-enabled using the
|
|||||||
until that setting is removed in a future release.
|
until that setting is removed in a future release.
|
||||||
|
|
||||||
Because there are many ways to expose TLS services from a Kubernetes cluster, the Supervisor app leaves this up to the user.
|
Because there are many ways to expose TLS services from a Kubernetes cluster, the Supervisor app leaves this up to the user.
|
||||||
The most common ways are:
|
Some common approaches are:
|
||||||
|
|
||||||
- Define a [TCP LoadBalancer Service](https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer).
|
- Define a [TCP LoadBalancer Service](https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer).
|
||||||
|
|
||||||
In this case, the Service is a layer 4 load balancer which does not terminate TLS, so the Supervisor app needs to be
|
In this case, the Service is a layer 4 load balancer which does not terminate TLS, so the Supervisor app needs to be
|
||||||
configured with TLS certificates and will terminate the TLS connection itself (see the section about FederationDomain
|
configured with TLS certificates and will terminate the TLS connection itself (see the section about FederationDomain
|
||||||
below). The LoadBalancer Service should be configured to use the HTTPS port 443 of the Supervisor pods as its `targetPort`.
|
below). The LoadBalancer Service should be configured to use the HTTPS port 8443 of the Supervisor pods as its `targetPort`.
|
||||||
|
|
||||||
- Or, define an [Ingress resource](https://kubernetes.io/docs/concepts/services-networking/ingress/).
|
This is the simplest way to expose the Supervisor's endpoints outside the cluster. If you are trying out Pinniped
|
||||||
|
for the first time, this is recommended during your trial. Before you move Pinniped into production, you may choose
|
||||||
|
to continue using a LoadBalancer Service, or you may prefer to explore one of the more complex setups described below,
|
||||||
|
depending on your networking requirements.
|
||||||
|
|
||||||
|
- Or, define an [Ingress resource](https://kubernetes.io/docs/concepts/services-networking/ingress/) (or use the newer [Gateway API](https://gateway-api.sigs.k8s.io)).
|
||||||
|
|
||||||
In this case, the [Ingress typically terminates TLS](https://kubernetes.io/docs/concepts/services-networking/ingress/#tls)
|
In this case, the [Ingress typically terminates TLS](https://kubernetes.io/docs/concepts/services-networking/ingress/#tls)
|
||||||
and then talks plain HTTP to its backend.
|
and then talks plain HTTP to its backend.
|
||||||
@ -115,10 +150,15 @@ create the Service will depend on how you choose to install the Supervisor:
|
|||||||
|
|
||||||
- If you installed using `ytt` then you can use
|
- If you installed using `ytt` then you can use
|
||||||
the related `service_*` options from [deploy/supervisor/values.yml](https://github.com/vmware-tanzu/pinniped/blob/main/deploy/supervisor/values.yaml)
|
the related `service_*` options from [deploy/supervisor/values.yml](https://github.com/vmware-tanzu/pinniped/blob/main/deploy/supervisor/values.yaml)
|
||||||
to create a Service.
|
to create a Service. This will expose the appropriate port.
|
||||||
- If you installed using the pre-rendered manifests attached to the Pinniped GitHub releases, then you can create
|
- If you installed using the pre-rendered manifests attached to the Pinniped GitHub releases, then you can create
|
||||||
the Service separately after installing the Supervisor app.
|
the Service separately after installing the Supervisor app.
|
||||||
|
|
||||||
|
⚠️ **Note:** Do not expose the Service called `pinniped-supervisor-api` outside the cluster.
|
||||||
|
That Service exists for a different purpose internal to the cluster, and it exposes a different port (10250).
|
||||||
|
Instead, create another Service to expose port 8443, by using the `ytt` options mentioned above or by manually
|
||||||
|
creating a Service as shown below.
|
||||||
|
|
||||||
There is no Ingress included in either the `ytt` templates or the pre-rendered manifests,
|
There is no Ingress included in either the `ytt` templates or the pre-rendered manifests,
|
||||||
so if you choose to use an Ingress then you'll need to create the Ingress separately after installing the Supervisor app.
|
so if you choose to use an Ingress then you'll need to create the Ingress separately after installing the Supervisor app.
|
||||||
|
|
||||||
@ -213,9 +253,13 @@ Each FederationDomain can be used to provide access to a set of Kubernetes clust
|
|||||||
|
|
||||||
### Configuring TLS for the Supervisor OIDC endpoints
|
### Configuring TLS for the Supervisor OIDC endpoints
|
||||||
|
|
||||||
If you have terminated TLS outside the app, for example using service mesh which handles encrypting the traffic for you,
|
If you have terminated TLS outside the Supervisor app as described in the section above for using a service mesh,
|
||||||
then you do not need to configure TLS certificates on the FederationDomain. Otherwise, you need to configure the
|
then you do not need to configure TLS certificates on the FederationDomain. Otherwise, you need to configure the
|
||||||
Supervisor app to terminate TLS.
|
Supervisor app with a TLS certificate.
|
||||||
|
|
||||||
|
The TLS certificate for the Supervisor should typically be created for the DNS name or IP address that your end users
|
||||||
|
will use to make requests to the Supervisor. This should be the same DNS name or IP address that you declared in the
|
||||||
|
FederationDomain's `spec.issuer`.
|
||||||
|
|
||||||
There are two places to optionally configure TLS certificates:
|
There are two places to optionally configure TLS certificates:
|
||||||
|
|
||||||
@ -228,11 +272,16 @@ Each incoming request to the endpoints of the Supervisor may use TLS certificate
|
|||||||
of the above ways. The TLS certificate to present to the client is selected dynamically for each request
|
of the above ways. The TLS certificate to present to the client is selected dynamically for each request
|
||||||
using Server Name Indication (SNI):
|
using Server Name Indication (SNI):
|
||||||
- When incoming requests use SNI to specify a hostname, and that hostname matches the hostname
|
- When incoming requests use SNI to specify a hostname, and that hostname matches the hostname
|
||||||
of a FederationDomain, and that FederationDomain specifies `spec.tls.secretName`, then the TLS certificate from the
|
of a FederationDomain's `spec.issuer` (case-insensitive hostname matching), and that FederationDomain
|
||||||
`spec.tls.secretName` Secret will be used.
|
specifies `spec.tls.secretName`, then the TLS certificate from the `spec.tls.secretName` Secret will be used.
|
||||||
- Any other request will use the default TLS certificate, if it is specified. This includes any request to a host
|
- Any other request will use the default TLS certificate, if it is specified. This includes any request to a host
|
||||||
which is an IP address, because SNI does not work for IP addresses. If the default TLS certificate is not specified,
|
which is an IP address, because SNI does not work for IP addresses. If the default TLS certificate is not specified,
|
||||||
then these requests will fail TLS certificate verification.
|
then these requests will fail TLS certificate verification and your end users will see the error message
|
||||||
|
`pinniped supervisor has invalid TLS serving certificate configuration`.
|
||||||
|
|
||||||
|
Your ingress software may require special configuration to enable the inclusion of the SNI information from the
|
||||||
|
original request into the requests that it makes to the Supervisor. Please refer the documentation for your ingress
|
||||||
|
solution for details.
|
||||||
|
|
||||||
It is recommended that you have a DNS entry for your load balancer or Ingress, and that you configure the
|
It is recommended that you have a DNS entry for your load balancer or Ingress, and that you configure the
|
||||||
OIDC provider's `issuer` using that DNS hostname, and that the TLS certificate for that provider also
|
OIDC provider's `issuer` using that DNS hostname, and that the TLS certificate for that provider also
|
||||||
|
File diff suppressed because one or more lines are too long
@ -9,6 +9,7 @@ code {
|
|||||||
}
|
}
|
||||||
pre code {
|
pre code {
|
||||||
background: none;
|
background: none;
|
||||||
|
font-size: 100%;
|
||||||
}
|
}
|
||||||
.highlight pre codesite/sidebar/reorganize {
|
.highlight pre codesite/sidebar/reorganize {
|
||||||
font-size: 100%;
|
font-size: 100%;
|
||||||
|
Loading…
Reference in New Issue
Block a user