Gitlab Environment Dashboard doesn't support well Flux Kustomizations across namespaces

Problem to solve

In Gitlab UI > Environment I can add a FluxCD Kustomization OK, but it will only shows pods and services in the namespace where the Kustomization resides. A FluxCD Kustomization can manage pods and services across namespaces. It is a common pattern like in https://github.com/fluxcd/flux2-kustomize-helm-example

---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: apps
  namespace: flux-system
spec:
  interval: 10m0s
  dependsOn:
    - name: infra-configs
  sourceRef:
    kind: GitRepository
    name: flux-system
  path: ./apps/production
  prune: true
  wait: true
  timeout: 5m0s

So I’m left having to create Kustomizations in each of my k8s namespaces and create Dashboards for each of these Kustomizations. Instead I would have preferred to have only the 2 Kustomizations Infrastructure and Apps reflected in 2 Environments in Gitlab Dashboard showing me both flux sync status + pods and services accross namespaces that each Kustomizations can reconciliate.

Could that be feasible ? Or are there better methods ?

Versions

Please select whether options apply, and add the version information.

• Self-managed
• GitLab Community Edition v17.8.7
• Gitlab agent v17.11.1
• FluxCD v2.5.1

I second this. In short Select Flux resource dropdown should not by restricted by k8s namespace.

What is funny, gitlab agent bootstrap itself creates a configuration that cannot be created manually (due to this limitation).
The automatically created flux-system/gitlab-agent environment has set gitlab-agent as a flux resource, but you cannot create this configuration manually if you wanted, as the resource won’t be found across namespace.

Screenshot 2025-07-15 at 14.57.291032×798 44.6 KB

I already don’t understand the “access” entries in the agent.yaml files. While I get the desire to select any flux resource, rbac is aliased on namespace boundaries so a. I can’t imagine this passing a security review and b. the implications of the security entries are already too obtuse for me to imagine how they would need to change to accomodate this.