Skip to main content
Version: 0.21.1

User Permissions

This is an explanation of the kubernetes permissions needed by users/groups of the Weave GitOps application. As covered in service account permissions the primary way that the application interacts with the Kube API is via impersonation. This means that the permissions granted to the users and groups that Weave GitOps can impersonate determine the scope of actions that it can take within your cluster.

At a minimum, a User should be bound to Role in the flux-system namespace (where flux stores its resources by default) with the following permissions:

rules:
# Flux Resources
- apiGroups: ["source.toolkit.fluxcd.io"]
resources: [ "buckets", "helmcharts", "gitrepositories", "helmrepositories", "ocirepositories" ]
verbs: [ "get", "list", "watch", "patch" ]

- apiGroups: ["kustomize.toolkit.fluxcd.io"]
resources: [ "kustomizations" ]
verbs: [ "get", "list", "watch", "patch" ]

- apiGroups: ["helm.toolkit.fluxcd.io"]
resources: [ "helmreleases" ]
verbs: [ "get", "list", "watch", "patch" ]

- apiGroups: [ "notification.toolkit.fluxcd.io" ]
resources: [ "providers", "alerts" ]
verbs: [ "get", "list", "watch", "patch" ]

- apiGroups: ["infra.contrib.fluxcd.io"]
resources: ["terraforms"]
verbs: [ "get", "list", "watch", "patch" ]

# Read access for all other Kubernetes objects
- apiGroups: ["*"]
resources: ["*"]
verbs: [ "get", "list", "watch" ]

For a wider scope the User can be bound to a ClusterRole with the same set.

Flux Resources

The resources that Flux works with directly, including the one from TF-controller.

Api GroupResourcesPermissions
kustomize.toolkit.fluxcd.iokustomizationsget, list, patch
helm.toolkit.fluxcd.iohelmreleasesget, list, patch
source.toolkit.fluxcd.iobuckets, helmcharts, gitrepositories, helmrepositories, ocirepositoriesget, list, patch
notification.toolkit.fluxcd.ioproviders, alertsget, list
infra.contrib.fluxcd.ioterraformsget, list, patch

In order for Weave GitOps to be able to accurately display the state of Flux it needs to be able to query the CRDs that Flux uses. This is done using the get and list permissions

The patch permissions are used for 2 features: to suspend and resume reconciliation of a resource by modifying the 'spec' of a resource, and to force reconciliation of a resource by modifying the annotations of the resource. These features work the same way flux suspend, flux resume and flux reconcile does on the CLI.

Resources managed via Flux

Api GroupResourcesPermissions
""configmaps, secrets, pods, services, persistentvolumes, persistentvolumeclaimsget, list, watch
appsdeployments, replicasets, statefulsetsget, list, watch
batchjobs, cronjobsget, list, watch
autoscalinghorizontalpodautoscalersget, list, watch
rbac.authorization.k8s.ioroles, clusterroles, rolebindings, clusterrolebindingsget, list, watch
networking.k8s.ioingressesget, list, watch

Weave GitOps reads basic resources so that it can monitor the effect that Flux has on what's running.

Reading secrets enables Weave GitOps to monitor the state of Helm releases as that's where it stores the state by default. For clarity this these are the Helm release objects not the Flux HelmRelease resource (which are dealt with by the earlier section).

Feedback from Flux

The primary method by which Flux communicates the status of itself is by events, these will show when reconciliations start and stop, whether they're successful and information as to why they're not.

Weave GitOps Enterprise Enterprise

Weave GitOps Enterprise extends Weave GitOps OSS by adding more roles. These roles may need to be extended further in order to support certain use cases. Some of the most common use cases are described below.

Progressive delivery with Flagger

Weave GitOps Enterprise integrates with Flagger in order to provide a view on progressive delivery deployments. This includes the ability to view all the resources that Flagger manages during its operation. The default ClusterRole gitops-canaries-reader includes the minimum permissions necessary for a user to be able to view canary object details, metric template object details and canary related events.

When Flagger is configured to integrate with a service mesh such as Linkerd or Istio for the rollout, then this ClusterRole needs to be extended so that it can read the additional service mesh resources being generated by Flagger. Note that currently, in order to display service mesh or ingress related resources, we require spec.provider to be set in each canary resource.

The following table provides a list of all the custom resources that Flagger generates grouped by provider:

ProviderAPI GroupResource
AppMeshappmesh.k8s.awsvirtualnode
appmesh.k8s.awsvirtualrouter
appmesh.k8s.awsvirtualservice
Linkerdsplit.smi-spec.iotrafficsplit
Istionetworking.istio.iodestinationrule
networking.istio.iovirtualservice
Contourprojectcontour.iohttpproxy
Gloogateway.solo.ioroutetable
gloo.solo.ioupstream
Nginxnetworking.k8s.ioingress
Skippernetworking.k8s.ioingress
Traefiktraefik.containo.ustraefikservice
Open Service Meshsplit.smi-spec.iotrafficsplit
Kumakuma.iotrafficroute
GatewayAPIgateway.networking.k8s.iohttproute

For example, the following manifest shows how gitops-canaries-reader has been extended to allow the user for viewing TrafficSplit resources when Linkerd is used:

Expand to see example canary reader RBAC
gitops-canaries-reader.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: gitops-canaries-reader
rules:
- apiGroups:
- flagger.app
resources:
- canaries
- metrictemplates
verbs:
- get
- list
- apiGroups:
- ""
resources:
- events
verbs:
- get
- watch
- list
# Additional permissions for Linkerd resources are added below
- apiGroups:
- split.smi-spec.io
resources:
- trafficsplits
verbs:
- get
- list

Setting up remote cluster permissions

In order to view canaries in a remote cluster from the management cluster, you need to consider the following:

  • The service account used to access the remote cluster needs to be able to list namespaces and custom resource definitions in the given cluster. It additionally needs to be able to impersonate users and groups.
  • The user or group that logs in to the management cluster, needs appropriate permissions to certain resources of the remote cluster.

For example, applying the following manifest on remote clusters, ensures that the wego-admin user will be able to view canary information from within the Weave GitOps Enterprise UI on the management cluster:

Expand to see example of remote cluster canary reader
remote-cluster-service-user-rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: user-groups-impersonator
rules:
- apiGroups: [""]
resources: ["users", "groups"]
verbs: ["impersonate"]
- apiGroups: [""]
resources: ["namespaces"]
verbs: ["get", "list"]
- apiGroups: ["apiextensions.k8s.io"]
resources: ["customresourcedefinitions"]
verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: impersonate-user-groups
subjects:
- kind: ServiceAccount
name: remote-cluster-01 # Service account created in remote cluster
namespace: default
roleRef:
kind: ClusterRole
name: user-groups-impersonator
apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: canary-reader
rules:
- apiGroups: [""]
resources: [ "events", "services" ]
verbs: [ "get", "list", "watch" ]
- apiGroups: [ "apps" ]
resources: [ "*" ]
verbs: [ "get", "list" ]
- apiGroups: [ "autoscaling" ]
resources: [ "*" ]
verbs: [ "get", "list" ]
- apiGroups: [ "flagger.app" ]
resources: [ "canaries", "metrictemplates"]
verbs: [ "get", "list", "watch" ]
- apiGroups: [ "helm.toolkit.fluxcd.io" ]
resources: [ "helmreleases" ]
verbs: [ "get", "list" ]
- apiGroups: [ "kustomize.toolkit.fluxcd.io" ]
resources: [ "kustomizations" ]
verbs: [ "get", "list" ]
- apiGroups: [ "source.toolkit.fluxcd.io" ]
resources: [ "buckets", "helmcharts", "gitrepositories", "helmrepositories", "ocirepositories" ]
verbs: [ "get", "list" ]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: read-canaries
subjects:
- kind: User
name: wego-admin # User logged in management cluster, impersonated via service account
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: canary-reader
apiGroup: rbac.authorization.k8s.io

You may need to add more users/groups to the read-canaries ClusterRoleBinding to ensure additional users can view canary information from within the Weave GitOps Enterprise UI.