limit perms for crds

[ReSearchITEng]

Request to access crds is usually a problem for non-admin users.

If we want to drastically limit to crds, what are the smallest list of perms required?

FYI, we have already set:

oc get cm postgres-operator -o yaml | grep crd
  enable_crd_validation: "false"

confirmed by:

oc patch crd postgresqls.acid.zalan.do -p '{"spec":{"validation": null }}'
customresourcedefinition.apiextensions.k8s.io/postgresqls.acid.zalan.do patched (no change)

But we get:

level=error msg="could not create customResourceDefinition \"postgresqls.acid.zalan.do\": customresourcedefinitions.apiextensions.k8s.io is forbidden: User \"system:serviceaccount:pg:postgres-operator\" cannot create resource \"customresourcedefinitions\" in API group \"apiextensions.k8s.io\" at the cluster scope" pkg=controller

Is this the minimum requried perm?

• apiGroups:
  • apiextensions.k8s.io
    resources:
  • customresourcedefinitions
    verbs:
  • get

PS: related to PR: https://github.com/zalando/postgres-operator/pull/599/files

[FxKu]

I'm a bit confused. It looks like you want something like our user-facing cluster roles.

Why disable CRD validation? That's to check if submitted manifest contain errors. The last error message has nothing to do with this. It just means the serviceAccount you are using does not have the permission to create a CRD. Have you change the operator cluster role? This one needs to be able to register CRDs and update them.

[ReSearchITEng]

@FxKu Thanks for clarification on enable_crd_validation .
As for your question:

Have you change the operator cluster role? This one needs to be able to register CRDs and update them.

Yes, we must restrict it to "get" verb only. The serviceAccounts we use (including pg opr serviceAccount) are not allowed to create/update crds. (crd deploy is done by admins, in flow before).
Why would it require? Is it mandatory or maybe we can put a parameter to skip it?

[machine424]

I also would like to prevent the operator from managing the CRDs, we want to the limit the operator ClusterRole permissions and we will deploy multiple postgres-operators so it's better that only admins have control on the CRDs.

Now, the operators log could not create customResourceDefinition, is it ok? they're not running on a degraded mode or something?

Also I would like to know if CRDs change a lot and if backward compatibility is always ensured (I think it's the case), basically I would like to know if using multiple operators is a good idea, I don't want all my pg clusters to rely on the same operators.

Thanks.

[neelasha-09]

@FxKu : We are facing the same issue in our cluster ? how can we avoid it ?