search

fluxcd / flux2

Open and extensible continuous delivery solution for Kubernetes. Powered by GitOps Toolkit.
https://fluxcd.io
Apache License 2.0
6.58k stars 608 forks source link

Please support --default-service-account and impersonation in source controller #5029

Closed tspearconquest closed 1 month ago

tspearconquest commented 1 month ago

Describe the bug

When reviewing our deployment of Flux and checking the docs, I noticed what I think may be a gap.

The source controller doesn't seem to have --default-service-account and while the flux multi-tenancy page does not include this controller, I think it should have this flag and be included in that page.

Steps to reproduce

  1. Install Flux
  2. Configure Flux for multi-tenancy
  3. Read the docs and the example code -- there is no spec.serviceAccountName field on the source custom resources; and no support for --default-service-account in the source controller, and the controller is not mentioned on the multi-tenancy page.

Expected behavior

Source controller can impersonate a service account in a namespace and reconcile the source custom resources with that service account instead of the pod service account which has cluster admin.

Screenshots and recordings

No response

OS / Distro

N/A

Flux version

2.3.0

Flux check

N/A

Git provider

Bitbucket

Container Registry provider

Cloudsmith

Additional context

While source controller doesn't reconcile kubernetes resources, it does reconcile GitRepository and HelmRepository resources status fields across namespaces unless --watch-all-namespaces=false or --watch-label-selector is passed to reduce what it watches.

Because of this, I think source controller should be able to be given the ability to impersonate a user in another namespace and similar to how we can configure kustomize and helm controllers, we should be able to configure a default service account for the source controller and specify the service account for reconciliation of the GitRepository, HelmRepository, HelmChart, and Bucket resources in each namespace.

Specifically, I'm trying to reduce the effective privileges of flux so that it leverages cluster admin only when absolutely necessary, and this controller (as well as notification controller, but that's another beast entirely) seems to continue to rely on the pod service account privileges while helm controller and kustomize controller can reconcile their respective (Kustomization, HelmRelease) resources with the privileges that those service accounts have.

Code of Conduct

tspearconquest commented 1 month ago

A bit more review and I found it's the custom role crd-controller-flux-system granting the privileges to the pod service account. Apologies.