Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

namespaced scoped client not working anymore #4

Open
raffaelespazzoli opened this issue Jan 10, 2022 · 6 comments
Open

namespaced scoped client not working anymore #4

raffaelespazzoli opened this issue Jan 10, 2022 · 6 comments

Comments

@raffaelespazzoli
Copy link
Collaborator

when a patch uses only namespaced resources, the namespaced client should be used.

@QuingKhaos
Copy link

@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.

@larsks
Copy link

larsks commented Sep 19, 2022

@raffaelespazzoli I just created #47, but this sounds like it may be the same issue.

@raffaelespazzoli
Copy link
Collaborator Author

the resource locker operator should work as you expect with namespace scoped permissions. the patch operator expects cluster-wide permissions.

@raffaelespazzoli
Copy link
Collaborator Author

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.

@QuingKhaos
Copy link

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.

larsks added a commit to larsks/nerc-ocp-config that referenced this issue Sep 23, 2022
The patch operator requires cluster-scoped permissions [1], but it
looks for service accounts per-namespace (yuck). For each namespace in
which we're deploying patches we'll need to add an additional
serviceaccount to the clusterrolebinding, and for each new resource
type we're patching we'll need to update the clusterrole.

[1]: redhat-cop/patch-operator#4
@jolbax
Copy link

jolbax commented Feb 15, 2024

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants