Commit Graph

8 Commits

Author SHA1 Message Date
Ryan Richard
8b7c30cfbd Supervisor listens for HTTPS on port 443 with configurable TLS certs
- TLS certificates can be configured on the OIDCProviderConfig using
  the `secretName` field.
- When listening for incoming TLS connections, choose the TLS cert
  based on the SNI hostname of the incoming request.
- Because SNI hostname information on incoming requests does not include
  the port number of the request, we add a validation that
  OIDCProviderConfigs where the issuer hostnames (not including port
  number) are the same must use the same `secretName`.
- Note that this approach does not yet support requests made to an
  IP address instead of a hostname. Also note that `localhost` is
  considered a hostname by SNI.
- Add port 443 as a container port to the pod spec.
- A new controller watches for TLS secrets and caches them in memory.
  That same in-memory cache is used while servicing incoming connections
  on the TLS port.
- Make it easy to configure both port 443 and/or port 80 for various
  Service types using our ytt templates for the supervisor.
- When deploying to kind, add another nodeport and forward it to the
  host on another port to expose our new HTTPS supervisor port to the
  host.
2020-10-26 17:03:26 -07:00
Ryan Richard
25a91019c2 Add spec.secretName to OPC and handle case-insensitive hostnames
- When two different Issuers have the same host (i.e. they differ
  only by path) then they must have the same secretName. This is because
  it wouldn't make sense for there to be two different TLS certificates
  for one host. Find any that do not have the same secret name to
  put an error status on them and to avoid serving OIDC endpoints for
  them. The host comparison is case-insensitive.
- Issuer hostnames should be treated as case-insensitive, because
  DNS hostnames are case-insensitive. So https://me.com and
  https://mE.cOm are duplicate issuers. However, paths are
  case-sensitive, so https://me.com/A and https://me.com/a are
  different issuers. Fixed this in the issuer validations and in the
  OIDC Manager's request router logic.
2020-10-23 16:25:44 -07:00
Ryan Richard
d9d76726c2 Implement per-issuer OIDC JWKS endpoint 2020-10-16 17:51:40 -07:00
Andrew Keesler
c555c14ccb
supervisor-oidc: add OIDCProviderConfig.Status.LastUpdateTime
Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-10-09 11:54:50 -04:00
Andrew Keesler
bb015adf4e
Backfill tests to OIDCProviderConfig controller
Signed-off-by: Andrew Keesler <akeesler@vmware.com>
2020-10-09 10:39:17 -04:00
Ryan Richard
8b7d96f42c Several small refactors related to OIDC providers 2020-10-08 11:28:21 -07:00
Andrew Keesler
da00fc708f
supervisor-oidc: checkpoint: add status to provider CRD
Signed-off-by: Ryan Richard <richardry@vmware.com>
2020-10-08 13:27:45 -04:00
Ryan Richard
6b653fc663 Creation and deletion of OIDC Provider discovery endpoints from config
- The OIDCProviderConfigWatcherController synchronizes the
  OIDCProviderConfig settings to dynamically mount and unmount the
  OIDC discovery endpoints for each provider
- Integration test passes but unit tests need to be added still
2020-10-07 19:18:34 -07:00