Privileges and RBAC

The short answer

cluster-admin is required to install, not to run. It is needed for two things that are cluster-scoped by nature:

1. Installing custom resource definitions.
2. Creating the cluster roles the three operators need.

Once installed, no component in the platform holds cluster-admin.

What is cluster-scoped

Custom resource definitions

From the bundled operators, not written by us.

CRD group	Installed by	Kinds
acid.zalan.do	Postgres operator	postgresqls, operatorconfigurations, postgresteams
kafka.strimzi.io	Kafka operator	kafkas, kafkatopics, kafkanodepools, strimzipodsets, and the Connect and Bridge kinds we do not use

CRDs are cluster-scoped in Kubernetes. There is no namespaced alternative.

Deleting a CRD deletes every resource of that kind, cluster-wide

Including any outside these two namespaces. If anything else in your cluster runs a Postgres or Kafka operator, removing these CRDs would take its databases and clusters with them.

Uninstall removes them by default, but checks first: if any of those kinds is in use outside the two namespaces it is removing, it skips the CRDs and says so. --keep-crds skips them unconditionally.

Cluster roles

Cluster role	Belongs to	What it is for
g0s-postgres-operator	Postgres operator	Managing Postgres clusters and their pods
g0s-postgres-operator-endpoints	Postgres operator	The endpoints permission its own upstream role omits, while still creating a master Endpoints object per cluster
postgres-pod	Postgres pods	What a database pod itself needs
strimzi-cluster-operator-global	Kafka operator	Cluster-scoped reconciliation
strimzi-cluster-operator-namespaced	Kafka operator	Namespaced resources, bound per namespace
strimzi-cluster-operator-leader-election	Kafka operator	Leader election
strimzi-cluster-operator-watched	Kafka operator	Watching the namespaces it manages
strimzi-kafka-broker	Kafka brokers	What a broker pod needs
strimzi-entity-operator	Topic and user operator	Managing topics and users
strimzi-kafka-client	Kafka clients	Client-side permissions
g0s-synapse-operator	Ingress operator	Watching Ingress objects and services

Eleven, and nine of them come straight from the two upstream operators.

The one we added, and why

g0s-postgres-operator-endpoints exists because the Postgres operator ships a cluster role without endpoints, yet creates a master Endpoints object for every cluster it manages. Without that rule, postgresql/core fails with endpoints is forbidden and the database never starts. See Postgres will not start.

What the application itself holds

The application services in gen0sec are not operators and do not watch the cluster.

Cluster-scoped permissions	None
Namespaced permissions	Reading their own configuration and secrets
Service accounts	One per service
Node access	None
Host mounts	None
Privileged containers	None

See Hardening for the container security context.

Can I install without cluster-admin?

Partly, if you split the install between two roles. This is a supported pattern but it is not the documented golden path, so plan for one extra iteration.

Step	Needs	Who
Apply CRDs	Cluster-scoped write on customresourcedefinitions	Your platform team, once per release
Create cluster roles and bindings	Cluster-scoped RBAC write	Your platform team, once
Install the three charts	Namespace-admin on both namespaces	The installer

Render what a chart would create, and hand that to whoever holds the privilege:

helm template g0s-infra $B/charts/gen0sec-infra-*.tgz \
  -n gen0sec-system -f $B/values/gen0sec-infra-values-onprem.yaml \
  | yq eval-all 'select(.kind == "ClusterRole" or .kind == "ClusterRoleBinding")'

Verifying after install

Confirm nothing holds more than it should:

kubectl get clusterrolebinding -o json \
  | jq -r '.items[]
      | select(.roleRef.name == "cluster-admin")
      | .metadata.name + "  ->  " + ([.subjects[]?.name] | join(","))'

No entry in that output should reference a gen0sec service account. If one does, tell us: that is a defect, not a configuration choice.

What an uninstall leaves behind

	Removed	Reason
Namespaced resources	Yes	Helm owns them
Objects the operators created outside the releases	Yes	The script removes them; helm uninstall alone does not
CRDs	Yes, unless in use elsewhere or --keep-crds	Removal is cluster-wide destructive, so the script checks before it acts
Cluster roles and bindings	Depends on the chart that created them	Check what remains and remove by hand if nothing else uses the operators

Uninstall reports what it removed and what it left.