search

weaveworks / weave-gitops

Weave GitOps provides insights into your application deployments, and makes continuous delivery with GitOps easier to adopt and scale across your teams.
https://docs.gitops.weave.works/
Apache License 2.0
924 stars 153 forks source link

Add 'check oidc-config' command #4146

Closed makkes closed 11 months ago

makkes commented 11 months ago

What changed?

A new command check oidc-config is introduced that validates a given OIDC configuration, either from a referenced Secret or from CLI flags.

Example for an invalid configuration:

$ gitops check oidc-config --scopes foobar -n weave-gitops
► Fetching OIDC configuration from Secret "weave-gitops/oidc-auth"
◎ Please open the following URL in your browser:

https://login.microsoftonline.com/XXX/oauth2/v2.0/authorize?access_type=offline&client_id=XXX&redirect_uri=http%3A%2F%2Flocalhost%3A9876&response_type=code&scope=foobar&state=state

Error: received error from identity provider: invalid_client (AADSTS650053: The application 'max-wego-oidc' asked for scope 'foobar' that doesn't exist on the resource '00000003-0000-0000-c000-000000000000'. Contact the app vendor. Trace ID: 06344505-ac86-47ad-acf9-d5c01efb1601 Correlation ID: b0c677e7-f13b-4d8b-8552-4859437cd877 Timestamp: 2023-11-22 11:14:06Z)

Example for a valid configuration:

$ go run ./cmd/gitops check oidc-config -n weave-gitops
► Fetching OIDC configuration from Secret "weave-gitops/oidc-auth"
◎ Opening browser. If this does not work, please open the following URL in your browser:

https://login.microsoftonline.com/XXX/oauth2/v2.0/authorize?access_type=offline&client_id=XXX&redirect_uri=http%3A%2F%2Flocalhost%3A9876&response_type=code&scope=openid+email+profile&state=state

✔ received response from OIDC provider
► exchanging code for token
user: tRbZyWwP7gpn-[...]-bkHbRdOKRmo0
groups: 579c2ee8-[...]-68bdb1a9fbf0

Why was this change made?

This will help users debug issues with Weave GitOps OIDC configuration as well as provide a way to validate a configuration before putting it on a cluster.

How was this change implemented?

The command consumes OIDC configuration from CLI flags or from a Secret on a cluster and sends the user through an OIDC authorization code flow. If it succeeds, the username and groups claims are logged to stdout. The command validates the Secret for missing fields and also prints all errors returned from the OIDC provider so that users know what went wrong.

How did you validate the change?

There are unit tests and I manually validated the command with Azure, Google and on-prem Keycloak as IdPs.

Release notes

New check oidc-config command for validating and debugging OIDC configuration.

Documentation Changes

added a link to the reference page at the bottom of this paragraph

makkes commented 11 months ago

Not sure why the test TestRefreshInvalidToken fails. It should really not be affected by anything within this PR.

yiannistri commented 11 months ago

Thank you @makkes :1st_place_medal: