CrunchyData
Ensure postgresclusters are available to admin/edit/view clusterroles
See https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles
Maintainer edit: https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles
@sathieu The commit message is fairly sparse. What is the rationale for this change?
Similarly, I believe if we included this, we'd have to do so on the kustomize based installer too.
@jkatz, I've added the kustomize part. I've not tested this part.
I've also added a createAggregateRoles value to the helm chart, defaulting to true.
You can see more info on aggregated roles by following the included links. My usecase is to allow a user having the admin role in a namespace to be able to create a postgresql cluster. This user already has permission to create deployement, pods, ... in the namespace so this is not a privilege escalation.
@sathieu Happy New Year! 🎉 Let me discuss with a few folks around what makes sense.
@jkatz I've rebased (and resolved a conflict). ANything I can do to move this forward?
@jkatz Please review (I've rebased).
IMO it makes sense to allow users with acces to a namespace to have the same access to PGO resources.
Quoting from doc:
[The
editcluster role] Allows read/write access to most objects in a namespace.This role does not allow viewing or modifying roles or role bindings. However, this role allows accessing Secrets and running Pods as any ServiceAccount in the namespace, so it can be used to gain the API access levels of any ServiceAccount in the namespace. This role also does not allow write access to Endpoints in clusters created using Kubernetes v1.22+. More information is available in the "Write Access for Endpoints" section.
[The
viewcluster role] Allows read-only access to see most objects in a namespace. It does not allow viewing roles or role bindings.This role does not allow viewing Secrets, since reading the contents of Secrets enables access to ServiceAccount credentials in the namespace, which would allow API access as any ServiceAccount in the namespace (a form of privilege escalation).