Add initial design doc for third party adding repos #1213
Conversation
| * As a consequence, the 3rd party can then link to directly deploy a chart from a repository in the Kubeapps UI. | ||
|
|
||
| ## Assumptions | ||
| - The same OpenID Connect identity provider must be used for both the 3rd party (such as Harbor) and Kubeapps (and by implication, the Kubernetes cluster). |
There was a problem hiding this comment.
AFAIK, the default scenario is to have Kubeapps/Harbor configured with username and password or the token, should we support this scenario?
There was a problem hiding this comment.
AFAIUI, Harbor only has username/password (called "database"), LDAP or OpenID Connect (see auth section of the user guide).
I'm keen to limit this initial integration to OpenID Connect for a couple of reasons:
- I'm actually keen for us (Kubeapps) to move towards recommending OpenID Connect as the default rather than token, with the k8s service account token being an option for a quick setup and testing, but not recommended for production use.
- It makes the integration trivial - since an
id_tokenfrom harbor is valid for Kubeapps/K8s if it's issued by the same identity provider). - It is a common auth across all three (harbor, kubeapps and the k8s api server).
Note that it doesn't exclude the systems using separate auth systems... a cookie credential could be used from harbor to Kubeapps as mentioned below (ie. a JS Fetch request with the include option for cross-origin cookies will send the kubeapps cookie once a user is auth'd), but this does not work for a token in localStorage - available only to the document's origin. So, unless we were wanting users to set a K8s service account token in the 3rd party app (?!), I think we're dependent on Kubeapps auth proxy to be able to have the 3rd party do api requests?
There was a problem hiding this comment.
I see. I agree with the reasoning. Maybe it's not something to discuss in this document but I wanted to clarify what happen if OIDC is not configured. I am not saying that we need to support it but at least plan to have that case covered (documentation or a proper error may be enough).
| string name = 1; | ||
| string url = 2; | ||
| } | ||
| // Later add credentials |
There was a problem hiding this comment.
we should probably design the scenario in which the repository require authentication (which is the default). In that case, it's necessary to specify those credentials as a secret. Who should create those secrets, the backend as part of this request or the third-party with a different request?
There was a problem hiding this comment.
From the third-party POV, I don't see any reason for that to be a separate request? So yes, I was assuming the former, that the single request to create an app repository in Kubeapps would include the creds (as hinted above) so the backend would create the AppRepository custom resource and the associated secrets (these are both in the namespace of the Kubeapps installation). What do you think? Let me know if you have other thoughts :)
There was a problem hiding this comment.
That sounds good to me. We just need to clarify that the user needs to have permissions enough to create secrets in the Kubeapps namespace.
| ## Implementation | ||
|
|
||
| ### Kubeapps | ||
| Kubeapps provides an api endpoint for app repositories: |
There was a problem hiding this comment.
I'm assuming we want to prevent external access to the Kubernetes API server (otherwise we could just use it directly instead), is that correct? Could this be as simple as a reverse proxy that only exposes the AppRepository CRD endpoints (e.g. a reverse proxy that to something like http://kubernetes.default/apis/kubeapps.com/v1/apprepositores)?
There was a problem hiding this comment.
Yes, we want to avoid directly access to the API server. Also, as discussed in my previous comment, we may want to create the App CRD and the associated secrets with a single request.
There was a problem hiding this comment.
Could this be as simple as a reverse proxy that only exposes the AppRepository CRD endpoints (e.g. a reverse proxy that to something like
http://kubernetes.default/apis/kubeapps.com/v1/apprepositores)?
Yeah I did think along these lines initially, but decided not to head that way as it is exposing Kubeapps implementation details which may change (ie. Kubeapps doesn't need to use a CRD for app repositories - in fact, see #1178 with Andres' proposal to change it... but whether or not that goes ahead at some point, it's an implementation detail which doesn't need to be exposed).
Harbor (or other repo UI) just know that kubeapps should now include repo x using provided credentials - and shouldn't care how Kubeapps keeps that state - both the repo details and the credentials, I think? WDYT? Happy to update the proposal to include that option if you think it's worthwhile considering more widely.
|
Thanks people. I'll go ahead and land this so I can point the harbor people at it, but do let me know if you've other thoughts. |
Ref: #1173
cc @migmartri and @prydonius in case you have time and are interested.