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.22.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

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

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

• HelmRelease
• Kustomizations
• Sources
  • GitRepostiories
  • OciRepositories
  • HelmRepositories
  • HelmCharts
  • Buckets

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 collector in flux-system namespace for any leaf cluster that you want to watch.

Expand to see an example

apiVersion: v1
kind: ServiceAccount
metadata:
  name: collector
  namespace: flux-system

2. Create a ClusterRole collector with the permissions to watch the supported resources.

Expand to see an example

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: collector
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" ]

3. Create a ClusterRolebinding collector to assign permissions to collector ServiceAccount.

Expand to see an example

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: collector
subjects:
  - kind: ServiceAccount
    name: collector
    namespace: flux-system
roleRef:
  kind: ClusterRole
  name: collector
  apiGroup: rbac.authorization.k8s.io

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

4. 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"

Next Steps

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