Generating permissions into permissions instead of clusterPermissions

[stanislavulrych]

Type of question

Open question

Question

The permissions for the go based operator are generated from kubebuilder annotations in controllers code. By default, the permissions are generated into (csv).spec.install.spec.clusterPermissions

What did you expect to see?

I would like to have the permissions listed in (csv).spec.install.spec.permissions

Is there a way how to modify the kubebuilder annotations to do so?

Environment

Operator type:

Kubernetes cluster type:

OpenShift

$ operator-sdk version

operator-sdk version: "v1.23.0", commit: "1eaeb5adb56be05fe8cc6dd70517e441696846a4", kubernetes version: "1.24.2", go version: "go1.18.5", GOOS: "linux", GOARCH: "amd64"

$ go version (if language is Go)

go version go1.18.7 linux/amd64

$ kubectl version

Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.0", GitCommit:"04ad1b56880418de7bd6feb9ff37a8518fbc1a0e", GitTreeState:"clean", BuildDate:"2022-05-12T09:52:02Z", GoVersion:"go1.17.5", Compiler:"gc", Platform:"linux/amd64"}

[OchiengEd]

@theishshah I can look into this

[OchiengEd]

hi @stanislavulrych You can achieve what you want by setting an arbitrary namespace in the kubebuilder rbac annotations. For example, if you want an operator to be able to create statefulsets and pods at the namespace level, it would look like shown below:

//+kubebuilder:rbac:groups=apps,resources=statefulset,namespace=placeholder,verbs=get;list;watch;create;update;patch;delete
//+kubebuilder:rbac:groups=core,resources=pods,namespace=placeholder,verbs=get;list;watch;create;update;patch;delete

Notice I have namespace set to namespace=placeholder.

While doing this will allow the cluster roles to be made to be roles, they would not be added to .spec.install.spec.permissions in the Cluster Service Version like you would expect it to. However, the role would be added as a separate file in the bundle/manifests directory.

Full path should take the pattern, bundle/manifests/[operator-name]-manager-role.rbac.authorization.k8s.io_v1_role.yaml

[stanislavulrych]

Hi @OchiengEd, thank you for the answer.

I have tried that and it really generates bundle/manifests/[operator-name]-manager-role.rbac.authorization.k8s.io_v1_role.yaml.

I just do not understand, why these permissions are not added to .spec.install.spec.permissions in the Cluster Service Version. Is there any special reason for it not being added to it?

[OchiengEd]

@stanislavulrych Not sure of the reason for this behavior. At this time, the issue has been marked as a bug and I believe Jesus will be looking into why the decision was made to have it as a separate file before any action can be taken.

[tlwu2013]

hey @stanislavulrych, are you completely blocked by this issue? If so, will it be possible for you to manually edit the .spec.install.spec.permissions in ClusterServiceVersion as a workaround for unblocking?

[stanislavulrych]

@tlwu2013 so far, I am building the operators without any manual steps, which is the reason why I opened this issue - it is possible to edit the CSV manually, however, you might understand that it somehow complicates the automated pipelines for the build.

[everettraven]

/unassign jmrodri

[sxd]

Hi Everyone!

There's any idea on continue the work on this issue?
I'm currently facing the same issue and I was having an idea that it's adding an option like --cluster-permission-to-permission (clearly not that long option) that switch the permission to the permission section.

The other idea is to add a --exclude-cluster-permission which basically exclude a set of permission resources of being moved into the permission section and being kept in the clusterPermission section, why? because some permissions like getting the nodes or namespace shouldn't be namespaced.

Any other idea on this?

[joelanford]

Operator SDK should already handle this automatically if you have a RoleBinding in your manifests that binds the operator's service account to the Role.

[stanislavulrych]

Hi everyone and @joelanford , in the later versions of operator-sdk, the documentation was greatly improved (thanks everyone involved for that!). By properly following the instructions in

https://sdk.operatorframework.io/docs/building-operators/golang/operator-scope/#changing-the-permissions-to-namespaced

and

https://sdk.operatorframework.io/docs/building-operators/golang/crds-scope/

I solved the problem of generating permissions instead of clusterpermissions. There is now really nothing to be added to those steps and the description is very informative. As described in the above, there is one manual step needed:

Use RoleBindings instead of ClusterRoleBindings. The config/rbac/role_binding.yaml needs to be manually updated

However, since role_binding.yaml is not regenerated during the operator build, it is not a problem even for automated build.

Thus,I am closing this.