text: Role Based Access Control
  Until Kubernetes 1.7, there were no permissions within a cluster. With the launch of 1.7, there is now a role based access control system (RBAC) which determines what services can perform actions within a cluster.
  RBAC affects a few different aspects of GitLab:
  - Installation of GitLab using Helm
  - Prometheus monitoring
  - GitLab Runner
  - In-cluster PostgreSQL database (when RBAC is enabled for it)
  - Certificate manager
  Checking that RBAC is enabled
  Try listing the current cluster roles, if it fails then
  RBAC is disabled
  This command will output
  false if
  RBAC is disabled and
  true otherwise
  kubectl get clusterroles > /dev/null 2>&1 && echo true || echo false
  Service accounts
  GitLab chart uses Service accounts to perform certain tasks. These accounts and their associated roles are created and managed by the chart.
  The service accounts are described in the following table. For each service account the table shows:
  - The name suffix (the prefix is the release name).
  - A short description, e.g. where it is used, what it is used for.
  - Associated roles and what level of access it has on which resources. Access level is either read-only (R), write-only (W), or read-write (RW). Note that group name of resources are omitted.
  - The scope of the roles, which is either the cluster (C) or the namespace (NS). In some instances the scope of the roles can be configured with either value (indicated by NS/C)
  GitLab chart depends on other charts that they also use RBAC and create their own service accounts and role binding. Here is an overview:
  - Prometheus monitoring creates multiple own service accounts by default. They are all associated to cluster level roles. For more information see Prometheus chart documentation.
  - Certificate manager creates a service account by default to manage its custom resources along with native resources at the cluster level. For more information see cert-manager chart RBAC template.
  - When you use in-cluster PostgreSQL database (this is the default) the service account is not enabled. You can enable it but it is only used to run PostgreSQL service and is not associated to any specific role. For more information see PostgreSQL chart.