This charm encompasses the Kubernetes Python operator for Kubeflow Roles (see CharmHub).
Implemented specifically in this charm are aggregation ClusterRoles used by Kubeflow to grant user access control.
Kubeflow uses the concept of user facing roles to provide access control to users. Kubeflow's instantiation of this pattern is described here. The ClusterRoles Kubeflow implements are are:
- rbac.authorization.kubeflow.org/aggregate-to-kubeflow-view
- rbac.authorization.kubeflow.org/aggregate-to-kubeflow-edit
- rbac.authorization.kubeflow.org/aggregate-to-kubeflow-admin
These ClusterRoles (see here for their definition in this charm) aggregate the permissions of all existing ClusterRoles that match a selector (in this case, ClusterRoles that have one of the rbac.authorization.kubeflow.org/aggregate-to-kubeflow-*: "true" labels), allowing permissions to be added to the aggregation roles without editing the roles themselves.
Permissions aggregated into these ClusterRoles cover both standard Kubernetes resources (e.g. Pods and Services), such as defined in this ClusterRole, as well as any access to custom resources. Applications in Kubeflow often add new CustomResources to the Kubernetes cluster that users must interact with, such as the Notebook object from the notebook-controller. To grant user access to these custom resources, applications must implement their own ClusterRoles that, through the label: rbac.authorization.kubeflow.org/aggregate-to-kubeflow-* labels, are aggregate into the above described roles.
To actually grant users the roles described in the aggregation ClusterRoles, Kubeflow's Profile Controller binds the above view and edit ClusterRoles to the ServiceAccounts of each user during the creation of profiles. This provides users access to everything defined in any of aggregated ClusterRoles.
The primary need for this charm is to implement the Kubeflow aggregation ClusterRoles as described above. Examples of these roles as implemented in the upstream manifests are here, where we have implemented our version here. These ClusterRoles do not naturally fit in any other charm and thus need a separate place for implementation.
For deployments which do not use all components of Kubeflow (for example, a Kubeflow implementation that omits Pipelines), we still create RBAC for users to interact with the Pipeline's resources. This could matter if an unrelated application on the cluster had similarly named resources.
To install Kubeflow Roles, run:
juju deploy kubeflow-roles
For more information, see https://juju.is/docs