Update design for external repo integration with note about repo access #1253
Conversation
| * the catalog provided by Kubeapps is not per namespace, but rather is the union of all configured app repositories, just like the helm CLI it emulates, and | ||
| * Kubeapps does not maintain a mapping of user privileges or internal RBAC - it relies on the Kubernetes cluster RBAC alone. | ||
|
|
||
| As we move toward Helm 3 by default, we could potentially resolve this by ensuring that AppRepositories, and the charts they reference, are per-namespace, so that the charts available can be limited to the repos in the namespaces to which the user has access. This would then mean that access to a project in Harbor would be equivalent to access to the Kubernetes namespace and could be controlled easily with oauth2 groups or otherwise configured, but this is outside the scope of this document. |
There was a problem hiding this comment.
maybe I have missed that but I didn't see that in Helm 3 the repos are going to be per namespace, where did you find that?
There was a problem hiding this comment.
Sorry - I didn't mean to imply that helm 3 repos themselves are per namespace, but rather than with helm 3, we would have the chance to ensure that AppRepositories created in a specific namespace are accessible only to users with access to that namespace. Currently we create the app repository resources in the kubeapps namespace and assume they're available to all users. There is nothing specifically related to helm3 which would allow us to do that, rather I just meant that helm 3 is generally making that move (from privileged accounts in the cluster to user privs only). Does that make more sense?
There was a problem hiding this comment.
I see, you are talking about a possible implementation. I am not sure if that would work (we may need to take a look to the authz implementation of the registry itself) because in theory, two persons with access to the same namespace may have different permissions to access a repository.
In any case, I don't think we need to cover that in this doc?
There was a problem hiding this comment.
Shouldn't you mention that the scope of the first integration is to only expose "public" repositories?
I think that decision is for the integrator. That is, if I'm using this functionality to enable access to a repository for a single Kubeapps installation, I need to know that I cannot currently restrict access to that repository on Kubeapps itself, and so would only use this functionality currently for chart repositories which I am happy for all users to access (public ones, perhaps, but not necessarily).
On the other hand, if I am using this functionality to enable access to repositories on different Kubeapps installations (even on different clusters), each with different users - with the understanding that all users of that Kubeapps installation will have access to the enabled repositories for that installation, then there is no issue.
| * the catalog provided by Kubeapps is not per namespace, but rather is the union of all configured app repositories, just like the helm CLI it emulates, and | ||
| * Kubeapps does not maintain a mapping of user privileges or internal RBAC - it relies on the Kubernetes cluster RBAC alone. | ||
|
|
||
| As we move toward Helm 3 by default, we could potentially resolve this by ensuring that AppRepositories, and the charts they reference, are per-namespace, so that the charts available can be limited to the repos in the namespaces to which the user has access. This would then mean that access to a project in Harbor would be equivalent to access to the Kubernetes namespace and could be controlled easily with oauth2 groups or otherwise configured, but this is outside the scope of this document. |
There was a problem hiding this comment.
Sorry - I didn't mean to imply that helm 3 repos themselves are per namespace, but rather than with helm 3, we would have the chance to ensure that AppRepositories created in a specific namespace are accessible only to users with access to that namespace. Currently we create the app repository resources in the kubeapps namespace and assume they're available to all users. There is nothing specifically related to helm3 which would allow us to do that, rather I just meant that helm 3 is generally making that move (from privileged accounts in the cluster to user privs only). Does that make more sense?
That said, I don't see how Kubeapps currently gets a valid |
Okay, yes, I agree, just wanted to clarify that.
That's a different issue. If the charts are working with private images, the secret with the credentials for that registry should be added manually and the charts should reference to that |
|
|
||
| As we move toward Helm 3 by default, we could potentially resolve this by ensuring that AppRepositories, and the charts they reference, are per-namespace, so that the charts available can be limited to the repos in the namespaces to which the user has access. This would then mean that access to a project in Harbor would be equivalent to access to the Kubernetes namespace and could be controlled easily with oauth2 groups or otherwise configured, but this is outside the scope of this document. | ||
|
|
||
| Given the current constraints, if an external application, such as harbor, enables a chart repository for a Kubeapps installation the charts of that repository will form part of the single app catalog available to all users of that installation. Although it is less than ideal, external applications could target different Kubeapps installations for different repos, but until Helm 3 is default and we have a chance to limit app repositories to namespaces, this may be the best option given the constraints. The important thing is that users of any integration understand that by enabling the repository in Kubeapps, it will currently mean that all Kubeapps users have access to the charts of the repository. |
There was a problem hiding this comment.
I'm not sure if I correctly understand the kubeapps scenario. Confirm here,
KubeApps will be deployed into the k8s cluster and it can only deploy apps to this k8s cluster it is in? The app catalog will be shared by the whole k8s cluster, no matter what namespaces?
There was a problem hiding this comment.
KubeApps will be deployed into the k8s cluster and it can only deploy apps to this k8s cluster it is in?
Correct: Kubeapps currently talks with the in-cluster Kubernetes API server (and tiller service).
The app catalog will be shared by the whole k8s cluster, no matter what namespaces?
Also correct :) Currently AppRepositories are created in the kubeapps namespace, and Kubeapps services use these to create the catalog of charts available to all users of that Kubeapps installation (which is effectively, the cluster).
This aims to capture the main concern raised by the Harbor team - but I'll check with them to ensure it is accurate before landing.