search

noobaa / noobaa-operator

Operator for NooBaa - object data service for hybrid and multi cloud environments :cloud: :wrench:
https://www.noobaa.io
Apache License 2.0
103 stars 101 forks source link

Noobaa authorization endpoint is hardcoded #351

Open gordillo-ramon opened 4 years ago

gordillo-ramon commented 4 years ago

Hi.

Recently, I tried to deploy noobaa using noobaa operator in a minikube, but it is raising an exception.

time="2020-06-25T10:56:56Z" level=warning msg="Discovery of OAuth endpoints failed, got: Get https://openshift.default.svc/.well-known/oauth-authorization-server: dial tcp: lookup openshift.default.svc on 10.96.0.10:53: no such host"

It seems it is becase in https://github.com/noobaa/noobaa-operator/blob/master/pkg/util/util.go#L54, the url is openshift.default.svc instead of kubernetes.default.svc.

nb-ohad commented 4 years ago

Hi @gordillo-ramon, Thank you for raising up the issue.

NooBaa currently supports Single Sign-On (Via OAuth2) only on top of OpenShift. The is the reason why the discovery endpoint always points to the .well-known endpoint OpenShift exposes.

When deploying on Kubernetes we just ignore it with a warning in our logs. This behavior should not interrupt the deployment process and noobaa login should be accessible via our management service (but without support for SSO) after the system is ready and deployment has finished.

Can you please elaborate a little bit about what are you trying to accomplish? I would like to map the gap between what is currently supported and your request.

rgordill commented 4 years ago

I have deployed that again, it works, but the oauth endpoint is not valid for vanilla k8s. If it is moved to kubernetes.default.svc, it should work the same, but also in k8s secured.

For my tests, it is not needed, but I can keep it open for your records.

nb-ohad commented 4 years ago

Hi @rgordill By current design, the auth endpoint is not supposed to be valid for vanilla k8s because we do not support SSO outside of OpenShift.

Supporting only the well-known is not enough as there are more steps that need to be taken after you acquire the OAuth2 endpoints.

OpenShift does not support a common protocol like OpenID so we resort to using proprietary APIs like tokenreviews after trading the grant code with an access token in order to authorize the user.

In order to support vanilla k8s we have to support some common-auth protocol like OpenID. So just changing the .well-known endpoint location is not enough.

I would like to know of any real use case for this kind of configuration. Which OAuth2 auth server is installed on the cluster and which provider it is supporting.