-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Idea: Fail-fast if clientID/clientSecret missing #244
Comments
I think we cannot simply fail to start Observatorium API, since we OIDC config is per tenant and we do not want one misconfigured tenant to bring the whole API down at the start-up. But there is a loop which tries to initiate the OIDC authenticator (with backoff), so if this keeps failing it should be logged + there's also a metric for that. On second thought, this sounds like the OIDC provider initiation actually succeeded, which should not have been the case without client ID / secret. |
I don't fully agree with this. This will mean one tenant's borked configuration breaks the API for everyone else. Ideally, if one tenant rolls out invalid configuration, other tenants can continue to use their API and even make changes of their own. Maybe it would be useful instead to have a utility to statically validate a tenant's configuration and be able to assert if they are valid before being applied to the server? This could be nice feature of the CLI.
I'm having a hard time imaging how the Observatorium fails to start up entirely if one tenant's OIDC config is missing an issuerURL. AFAICT:
|
Observatorium-API refuses to start if IssuerURL is empty:
https://github.com/observatorium/api/blob/main/authentication/oidc.go#L78
It would also be helpful if Observatorium-API failed to start without clientID or clientSecret. I spent about 20 minutes struggling because I had left clientID blank.
With a bogus tenant.yaml containing
Observatorium came up fine, but GRPC clients who sent valid headers saw:
That message makes no sense to clients, only to Observatorium implementors. I assume HTTP clients delivering logs would see something similar.
The text was updated successfully, but these errors were encountered: