redhat-cop
namespaced scoped client not working anymore
when a patch uses only namespaced resources, the namespaced client should be used.
@raffaelespazzoli Could this be a similar problem, that runtime patches can't use a service account which has only access to a specific namespace? The patch fails with an permission errors, that it isn't allowed to watch the given resource cluster-wide.
@raffaelespazzoli I just created #47, but this sounds like it may be the same issue.
the resource locker operator should work as you expect with namespace scoped permissions. the patch operator expects cluster-wide permissions.
this is fixable, but I never really invested time in fixing it as the patch operator is in my mind for admins that would have cluster-wide permissions anyhow. Should this become a requirement we can think about it.
Yes, patch-operator is an admin tool, but following least privilege principle, we don't want the service account used by the Patch to have cluster-wide permissions.
Additionally, we manage Patches via GitOps (ArgoCD), so each Patch gets its own service account and scoped RBAC permissions. We'd like to scope those permissions to exactly the objects the Patch is supposed to patch. This prevents fuck-ups like patching all secrets in a cluster too (I used a negative/notIn label selector and forgot the namespace on the target objects). Since you need already a service account per namespace where you create a patch, it doesn't matter if we create one per patch, as they are encapsulated per Argo Application.
But there are also valid use cases for developers. Given a namespace scoped ArgoCD instance for a dev team, which has no cluster-scoped permissions. There is a need to create patches for some CRD constructs. For example pgBackRest from the crunchy-postgres-operator expects the S3 credentials in a specific config file format. So a creation-time patch is used to create the secret based on the secret data from the ObjectBucketClaim. Of course this is abstracted in our own internal Helm chart, but the Patch must be able to run on namespace only permissions.
this is fixable, but I never really invested time in fixing it as the patch operator is in my mind for admins that would have cluster-wide permissions anyhow. Should this become a requirement we can think about it.
Hi @raffaelespazzoli - for us (in the org I work for ) is the statement of @QuingKhaos also a reason stopping us to use the patch operator. As the resource locker operator is an archived project we are really looking forward to migrate/move to the patch operator. But not at cost of loosing our "least privilege principle" strategy.
Is this an enough eloquent explanation for this issue to become a requirement?
