Enable Kubernetes RBAC for GitLab Managed Apps for existing clusters
EE MR at https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/6946
What does this MR do?
Enables support for users to add existing RBAC clusters:-
- Allows users to install Helm into an RBAC cluster
- Allows users to install and run the other GitLab Managed apps (ingress, etc)
It works by :
- Creating a
tiller
service account in thegitlab-managed-apps
namespace for Helm Tiller's use. - Providing cluster-wide access tp the
tiller
service account.
This MR includes the creation of the Gitlab::Kubernetes::KubeClient
proxy class which I created to work around the limitation of Kubeclient
which can only support one k8s api endpoint at a time (e.g. /api/v1
). This proxy class works by delegating listed get_*
, watch_*
, delete_*
, create_*
, update_*
and patch_*
methods to the Kubeclient::Client that responds to the entity method.
E.g. :
-
get_pod
is in the k8s/api/v1
group. So a Kubeclient::Client with that endpoint will respond toget_pod
. Our proxy will send the message to this client. -
get_cluster_role_binding
is in the k8sapis/rbac.authorization.k8s.io
group. Another Kubeclient::Client which has this endpoint will respond toget_cluster_role_binding
. Our proxy will send the message to this client.
NOTE: See also https://github.com/abonas/kubeclient/issues/208#issuecomment-412706681
What are the relevant issue numbers?
Notes and screenshot
This feature is hidden behind a feature flag (:rbac_clusters
).
To enable the feature flag, go to a rails console :
Feature.enable('rbac_clusters')
Once the feature flag is enabled, users will be able to see and select RBAC-enabled cluster
when adding an existing Kubernetes cluster.
NOTE: Auto DevOps will not successfully complete in an RBAC-enabled cluster. This is planned to be supported at a later stage in this issue
Development tasks
-
DB Migration : authorization_type
for clusters_platforms_kubernetes -
If cluster
forClusters::Applications::Helm
is rbac, install Helm Tiller with--service-account
-
Create service account e.g. tiller
ingitlab-managed-apps
namespace with [relevant permissions] -
create clusterrolebinding
to bindcluster-admin
clusterrole totiller
serviceAccount. -
helm init --service-account tiller
-
also installing helm apps should set rbac.create=true
.helm install --set rbac.create=true <chart>
-
-
Feature flag this. When the user/admin enables the "experimental RBAC support" feature flag (auto devops and web terminal support coming soon), then the front-end form will now include a check-box "RBAC-enabled cluster"
QA
QA scripts will :
- Check we can install cluster applications on a ABAC cluster
Manual QA:
See https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21127#note_98930304 for details and video
-
Check that ABAC clusters should still work -
Check that helper applications (tiller, ingress, etc) are still working as expected
-
-
Check that we can install cluster applications on RBAC enabled cluster -
Check that helper applications (tiller, ingress, etc) are still working as expected
-
-
Provide apps read access outside the namespace (if not provided by default) - I can route with nginx-ingress to a production app (which is on a namespace
rails-prometheus-9
, that is outside ofgitlab-managed-apps
) on my RBAC cluster.
- I can route with nginx-ingress to a production app (which is on a namespace
Does this MR meet the acceptance criteria?
-
Changelog entry added, if necessary -
Documentation created/updated - https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21323 -
Tests added for this feature/bug -
Conforms to the code review guidelines -
Conforms to the merge request performance guidelines -
Conforms to the style guides -
Conforms to the database guides