GitOps Dashboard Service Account Permissions

Important

This doc covers the service account permissions for the Weave Gitops application itself (ie. the permissions the Dashboard needs to work). For the service account for the cluster user role (ie. for the user accessing the GitOps Dashboard), see the page here.

The default permissions of the service account are defined in the helm chart which will generate a cluster role with the following permissions:

rules:
# Used to query the cluster
- apiGroups: [""]
  resources:  ["users", "groups"]  # set by rbac.impersonationResources
  verbs: [ "impersonate" ]
  # resourceNames: []              # set by rbac.impersonationResourceNames
# Used to get OIDC/static user credentials for login
- apiGroups: [""]
  resources: [ "secrets" ]
  verbs: [ "get", "list" ]
  resourceNames:                  # set by rbac.viewSecretsResourceNames
    - "cluster-user-auth"
    - "oidc-auth"
# The service account needs to read namespaces to know where it can query
- apiGroups: [ "" ]
  resources: [ "namespaces" ]
  verbs: [ "get", "list" ]

These allow the pod to do three things:

• Impersonate the user and operate in the cluster as them
• Read the available namespaces (this is required to understand the users' permissions)
• Read the cluster-user-auth and oidc-auth secrets, which are the default secrets to store the emergency cluster user account and OIDC configuration (see securing access to the dashboard)

The Helm values

Value	Description	Default
rbac.impersonationResources	Which resource types the service account can impersonate	["users", "groups"]
rbac.impersonationResourceNames	Specific users, groups or services account that can be impersonated	[]
rbac.viewSecretsResourceNames	Specific secrets that can be read	["cluster-user-auth", "oidc-auth"]

Impersonation

The primary way Weave GitOps queries the Kube API is via impersonation, the application (not the cluster) authenticates the user (either via the emergency cluster user credentials or OIDC) then makes calls to the Kube API on the user's behalf. This is equivalent to making a kubectl call like:

$ kubectl get deployments --as aisha@example.com

Assuming the user aisha@example.com has been granted permissions to get deployments within the cluster then this will return them. The same occurs within the application. This makes the proper configuration of the application's permissions very important as, without proper restrictions it can impersonate very powerful users or groups. For example, the system:masters is group is generally bound to the cluster-admin role which can do anything.

For more details of the permissions needed by the user or group see the user permissions guide.

Configuring impersonation

It is highly recommended that you limit which users and groups that the application can impersonate by setting rbac.impersonationResourceNames in the Helm chart's values. e.g.:

rbac:
  impersonationResources: ["groups"]
  impersonationResourceNames:
    - admin
    - dev-team
    - qa-team

In this example the application can only impersonate the groups admin, dev-team and qa-team (this also, implicitly disables the emergency cluster user).

Unfortunately not all OIDC providers support groups so you may need to manually enumerate users, for example:

rbac:
  impersonationResources: ["users"]
  impersonationResourceNames:
    - aisha@example.com
    - bill@example.com
    - wego-admin         # enable the emergency cluster user

A better, albeit more involved, solution is to set up an OIDC connector like Dex and use that to manage groups for you.

Get namespaces

The application itself uses get namespace permissions to pre-cache the list of available namespaces. As the user accesses resources their permissions within various namespaces is also cached to speed up future operations.

Reading the cluster-user-auth and oidc-auth secrets

The cluster-user-auth and oidc-auth secrets provide information for authenticating to the application. The former holds the username and bcrypt-hashed password for the emergency user and the latter holds OIDC configuration.

The application needs to be able to access these secrets in order to authenticate users.

Configuring secrets

The rbac.viewSecretsResourceNames value allows the operator to change which secrets the application can read. This is mostly so that, if the emergency user is not configured, that secret can be removed, or if the secret is in use but renamed.