Securing access to the dashboard

Dashboard Login

There are 2 supported methods for logging in to the dashboard:

• Login via an OIDC provider
• Login via a cluster user account

The recommended method is to integrate with an OIDC provider, as this will let you control permissions for existing users and groups that have already been configured to use OIDC. However, it is also possible to use a cluster user account to login, if an OIDC provider is not available to use. Both methods work with standard Kubernetes RBAC.

FEATURE TOGGLE

The following instructions describe a feature that is behind a feature toggle. To enable this feature, set the following OS environment variable:

export WEAVE_GITOPS_AUTH_ENABLED=true

Login via an OIDC provider

Weave GitOps

You may decide to give your engineering teams access to the dashboard, in order to view and manage their workloads. In this case, you will want to secure access to the dashboard and restrict who can interact with it. Weave GitOps integrates with your OIDC provider and uses standard Kubernetes RBAC to give you fine-grained control of the permissions for the dashboard users.

Background

OIDC extends the OAuth2 authorization protocol by including an additional field (ID Token) that contains information (claims) about a user's identity. After a user successfully authenticates with the OIDC provider, this information is used by Weave GitOps to impersonate the user in any calls to the Kubernetes API. This allows cluster administrators to use RBAC rules to control access to the cluster and also the dashboard.

Configuration

In order to login via your OIDC provider, you need to create a Kubernetes secret to store the OIDC configuration. This configuration consists of the following parameters:

Parameter	Description	Default
IssuerURL	The URL of the issuer, typically the discovery URL without a path
ClientID	The client ID that has been setup for Weave GitOps in the issuer
ClientSecret	The client secret that has been setup for Weave GitOps in the issuer
RedirectURL	The redirect URL that has been setup for Weave GitOps in the issuer, typically the dashboard URL followed by /oauth2/callback
TokenDuration	The time duration that the ID Token will remain valid, after successful authentication	"1h0m0s"

Ensure that your OIDC provider has been setup with a client ID/secret and the redirect URL of the dashboard.

Create a secret named oidc-auth in the wego-system namespace with these parameters set:

kubectl create secret generic oidc-auth \
  --namespace wego-system \
  --from-literal=issuerURL=<oidc-issuer-url> \
  --from-literal=clientID=<client-id> \
  --from-literal=clientSecret=<client-secret> \
  --from-literal=redirectURL=<redirect-url> \
  --from-literal=tokenDuration=<token-duration>

Once the HTTP server starts, it will redirect unauthenticated users to the provider's login page to authenticate them. Upon successful authentication, the users' identity will be impersonated in any calls made to the Kubernetes API, as part of any action they take in the dashboard. At this point, the dashboard will fail to render correctly unless RBAC has been configured accordingly. Follow the instructions in the RBAC authorization section in order to configure RBAC correctly.

Weave GitOps Enterprise

Weave GitOps Enterprise builds upon the Weave GitOps functionality that allows users to secure the dashboard and use RBAC to control access.

Configuration

Before enabling this feature, you need to add a secret in the wego-system namespace containing the clientId and clientSecret for the client app used. Ensure that your OIDC issuer provider has been setup correctly with the same client app details.

kubectl create secret generic client-credentials \
  --namespace wego-system \
  --from-literal=clientId=<client-id> \
  --from-literal=clientSecret=<client-secret>

Once the secret has been added to the cluster, run the gitops upgrade command and set the following OIDC parameters accordingly:

gitops upgrade --config-repo https://github.com/my-org/ my-repo --version 0.0.16 \
  --set config.oidc.enabled=true \
  --set config.oidc.clientCredentialsSecret=client-credentials \
  --set config.oidc.issuerURL=<URL of the OIDC issuer> \
  --set config.oidc.redirectURL=<Weave GitOps Enterprise callback URL>

The <Weave GitOps Enterprise callback URL> should be set to the URL that the dashboard is hosted at, postfixed with /oauth2/callback. For example: https://gitops.example.com/oauth2/callback.

UPDATING OIDC CONFIGURATION

If you need to change the OIDC configuration after running gitops upgrade, update the corresponding HelmRelease manifest for Weave GitOps Enterprise in the git repository.

Login via a cluster user account

Before you login via the cluster user account, you need to generate a bcrypt hash for your chosen password and store it as a secret in Kubernetes. There are several different ways to generate a bcrypt hash, this guide uses a Go Docker image to generate one:

Run an Alpine Docker image interactively and supply the password of your choice as an environment variable:

PASSWORD="<your password>"
docker run -it golang:1.17 bash -c "go install github.com/bitnami/bcrypt-cli@v1.0.2 2> /dev/null && echo -n '$PASSWORD' | bcrypt-cli"
$2a$10$OS5NJmPNEb13UTOSKngMxOWlmS7mlxX77hv4yAiISvZ71Dc7IuN3q

Now create a Kubernetes secret to store your chosen username and the password hash:

kubectl create secret generic cluster-user-auth \
  --namespace flux-system \
  --from-literal=username=admin \
  --from-literal=password='$2a$10$OS5NJmPNEb13UTOSKngMxOWlmS7mlxX77hv4yAiISvZ71Dc7IuN3q'

You should now be able to login via the cluster user account using your chosen username and password. Follow the instructions in the next section in order to configure RBAC correctly.

RBAC authorization

Both login methods work with standard Kubernetes RBAC. The following roles represent the minimal set of permissions needed to view applications, commits and profiles from the dashboard:

apps-profiles-reader.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: apps-reader
  namespace: wego-system
rules:
  - apiGroups: ["wego.weave.works"]
    resources: ["apps"]
    verbs: ["get", "list"]
  - apiGroups: ["source.toolkit.fluxcd.io"]
    resources: ["gitrepositories"]
    verbs: ["get"]
  - apiGroups: ["source.toolkit.fluxcd.io"]
    resources: ["helmrepositories"]
    verbs: ["get"]
  - apiGroups: ["kustomize.toolkit.fluxcd.io"]
    resources: ["kustomizations"]
    verbs: ["get"]
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get"]
    resourceNames: ["wego-github-dev-cluster"] # name of secret created by Weave GitOps that contains the deploy key for the git repository
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: profiles-reader
  namespace: wego-system
rules:
  - apiGroups: ["source.toolkit.fluxcd.io"]
    resources: ["helmrepositories"]
    verbs: ["get"]
    resourceNames: ["weaveworks-charts"]

The following role represents the minimal set of permissions needed to add applications from the dashboard:

apps-writer.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: apps-writer
rules:
  - apiGroups: ["apiextensions.k8s.io"]
    resources: ["customresourcedefinitions"]
    verbs: ["get"]
    resourceNames: ["apps.wego.weave.works"]

The table below contains all the permissions that the dashboard uses:

Resource	API Group	Action	Description
apps	wego.weave.works	list	Required to list all applications
apps	wego.weave.works	get	Required to retrieve a single application
gitrepositories	source.toolkit.fluxcd.io	get	Required to retrieve a single application
kustomizations	kustomize.toolkit.fluxcd.io	get	Required to retrieve a single application
gitrepositories	source.toolkit.fluxcd.io	update	Required to sync an application
helmrepositories	source.toolkit.fluxcd.io	update	Required to sync an application
kustomizations	kustomize.toolkit.fluxcd.io	update	Required to sync an application
secrets		get	Required to read deploy key secret in order to retrieve the list of commits
customresourcedefinitions	apiextensions.k8s.io	get	Required to read custom resources of type apps.wego.weave.works when adding an application

In order to assign permissions to a user, create a RoleBinding/ClusterRoleBinding. For example, the following role bindings assign all dashboard permissions to the admin user:

admin-role-bindings.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-apps
  namespace: wego-system
subjects:
- kind: User
  name: admin
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: apps-reader
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-profiles
  namespace: wego-system
subjects:
- kind: User
  name: admin
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: profiles-reader
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: write-apps
subjects:
- kind: User
  name: admin
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: apps-writer
  apiGroup: rbac.authorization.k8s.io

To test whether permissions have been setup correctly for a specific user/group use the kubectl auth can-i subcommand:

kubectl auth can-i list apps --as "admin" --namespace wego-system

For more information about RBAC authorization visit the Kubernetes reference documentation.