Skip to main content
Version: 0.32.0

Configuration Enterprise

caution

This feature is in alpha and certain aspects will change

We're very excited for people to use this feature. However, please note that changes in the API, behaviour and security will evolve. The feature is suitable to use in controlled testing environments.

This page helps you to understand the options available to configure Explorer

Prerequisites​

Before using Explorer, please ensure that:

  • You have Weave Gitops Enterprise v0.23.0

Setup​

The following configuration options are available for you to setup Explorer.

  • .spec.values.enableExplorer: feature flag to control whether Explorer is enabled.
  • .spec.values.useQueryServiceBackend: feature flag to control whether you want to leverage Explorer backend capabilities for other UI experiences like Applications or Sources
  • .spec.values.explorer.collector.serviceAccount: ServiceAccount name and namespace that explorer collector will use to impersonate in leaf clusters. Make sure you read authz for collector before setting it. Default values are name: collector, namespace: flux-system.

You should specify them in your HelmRelease values:

---
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: weave-gitops-enterprise
  namespace: flux-system
spec:
  # ... other spec components
  values:
    enableExplorer: true # feature flag to enable explorer
    useQueryServiceBackend: true # uses explorer query backend in collection UIs
    explorer:
      collector:
        serviceAccount: # service account that collector will impersonate in leaf clusters
          name: collector
          namespace: flux-system

Configuration​

Clusters​

Explorer watches the GitopsClusters that you have connected to Weave Gitops Enterprise, as well as your Management cluster.

Kinds​

Explorer watches for the following kind resources out of the box:

Flux GitOps Toolkit

Data Layer​

Explorer take a simple approach to manage resource views. It leverages a Data Store for caching the views and query them. The storage lifecycle is bounded to Weave Gitops Enterprise app and does not provide persistence guarantees. Instead, it requests data as required to the leaf clusters. In its simplest form, the data store used is SQLite.

Authentication and Authorization​

There are two main paths to consider within Explorer in the context of authentication and authorization (authN/authZ):

  1. The read or querying path is exercised when a weave gitops user queries the data.
  2. The write or collecting path is exercised to gather the resources from the leaf clusters.

We look into them separately.

Authentication and Authorization for querying​

Explorer leverages existing authentication and authorization built-in the application. It identifies for a user logged in the application: its identity and the access permissions via Kuberentes RBAC. Query results are filtered honouring the access determined via RBAC.

Authentication and Authorization for collecting​

GitopsClusters define the connection and security context that Explorer leverages to collect data from leaf clusters. Given that you have followed the indications in setup RBAC, the GitopsCluster service account is able to impersonate any user or group.

tip

Collector RBAC resources are part of your leaf clusters common RBAC configuration. It is commonly located in your clusters/bases folder, as described in Getting started.

To configure collection, you would need to extend this configuration with the following:

  1. Create a ServiceAccount for the one that you specified in your setup .spec.values.explorer.collector.serviceAccount.
Expand to see an example
apiVersion: v1
kind: ServiceAccount
metadata:
  name: collector # should match .spec.values.explorer.collector.serviceAccount.name
  namespace: flux-system # should match .spec.values.explorer.collector.serviceAccount.namespace
  1. Create a ClusterRole with the permissions to watch the supported resources.
Expand to see an example
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: collector # could be .spec.values.explorer.collector.serviceAccount.name
rules:
  - apiGroups: [ "rbac.authorization.k8s.io" ]
    resources: [ "roles", "clusterroles", "rolebindings", "clusterrolebindings" ]
    verbs: [ "list", "watch" ]
  - apiGroups: [ "kustomize.toolkit.fluxcd.io" ]
    resources: [ "kustomizations" ]
    verbs: [ "list", "watch" ]
  - apiGroups: [ "helm.toolkit.fluxcd.io" ]
    resources: [ "helmreleases" ]
    verbs: [ "list", "watch" ]
  - apiGroups: [ "source.toolkit.fluxcd.io" ]
    resources: [ "buckets", "helmcharts", "gitrepositories", "helmrepositories", "ocirepositories" ]
    verbs: [ "list", "watch" ]
  1. Create a ClusterRolebinding to assign previous ClusterRole to the created collector ServiceAccount.
Expand to see an example
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: collector # could be .spec.values.explorer.collector.serviceAccount.name
subjects:
  - kind: ServiceAccount
    name: collector # should match .spec.values.explorer.collector.serviceAccount.name
    namespace: flux-system # should match .spec.values.explorer.collector.serviceAccount.namespace
roleRef:
  kind: ClusterRole
  name: collector # name of the cluster role created earlier
  apiGroup: rbac.authorization.k8s.io

If you want the collector to watch a particular namespace use a RoleBinding instead.

  1. Extend impersonation rules to allow service account impersonation for ServiceAccount collector
Expand to see an example
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: clusters-service-impersonator-role
rules:
  - apiGroups: [""]
    resources: ["users", "groups"]
    verbs: ["impersonate"]
  - apiGroups: [ "" ]
    resources: [ "serviceaccounts" ]
    verbs: [ "impersonate" ]
    resourceNames:
      - "collector" # should match .spec.values.explorer.collector.serviceAccount.name

Next Steps​

  • See querying to deep dive in how to query.
  • See operations for day troubleshooting and operations.