Skip to main content
Warning This document has not been updated for a while now. It may be out of date.
Last updated: 2 Dec 2021

govuk-infrastructure: 10. Use Dex IdP for user web auth

Date: 2021-12-01

Status

Accepted

Context

We want to implement user authentication on the monitoring stack's web applications (Grafana, Prometheus, Alertmanager).

We also want to use Github as the identity provider (IdP), as that provides a means for us to control access based on GDS Github organisation and team membership; the alternative option, GSuite, does not currently have the granular role/group structure that we would require to effectively control access, and introducing that group structure would be out of scope for this project, and would likely replicate the Github group/team structure that currently exists.

Grafana supports many authentication methods, including Github OAuth2 and OIDC (via generic OAuth2).

Prometheus and Alertmanager do not support any form of web-based user authentication, so this must be handled via a proxy or load balancer in front of the application.

We are currently using ALBs in front of Prometheus and Alertmanager, via the AWS Load Balancer Controller, which supports authentication via AWS Cognito or OIDC-compliant identity providers.

Github as an IdP does not support OIDC, only OAuth2, so cannot be used with ALB auth. AWS Cognito does not support OAuth2, only OIDC, so cannot be used with Github as an IdP.

ArgoCD, our current CD tool, also implements authentication via OIDC, and includes an OIDC-compliant identity broker, Dex.

In summary, OIDC is the only auth protocol supported universally by both our current web-based UIs that support authentication internally, and by ALBs for apps that do not. Github however does not provide an OIDC-compliant IdP.

Decision

Use Dex as an SSO service and identity provider for all web-based user authentication. This is strictly for use with user-facing web-based cluster services such as monitoring and CI/CD tools, and should not be used for any other purposes such as AWS or Kubernetes authentication.

Consequences

We will have a single signon (SSO) service and consistent identity provider for all user-facing platform UIs, now and in the future. This will provide a single point of integration with the underlying identity provider (Github), and so only one component will need a configuration change in the event that the identity provider changes in the future (for example, to Google or Active Directory).

Dex is currently deployed as a component of the larger Argo service. As Dex will now be a shared platform service, this should be removed in favour of a standalone Dex Helm install.

As a single signon service, Dex is also a single point of failure and a clear potential target for attack. As such Dex must be highly available, secure, and covered in the scope of penetration testing.