best-practices regarding RBAC configuration for a new CRD

[Michael Greenberg]

I am looking for a best-practices regarding RBAC configuration for a new CRD.

When an "end-user" tries to create a CR from the sample generated by the operator SDK (1.2.0) config/samples/<GROUP>_v1alpha1_<KIND>.yaml an RBAC error is generated:

Error from server (Forbidden): error when creating "config/samples/..."

The Operator SDK had generated files:

config/rbac/<KIND>_editor_role.yaml
config/rbac/<KIND>_viewer_role.yaml

but there is no Operator SDK documentation/recommendations how they should be used. The only reference to these files is in the Restricting Roles and permissions section:

.. are not relevant to changing the operator’s resource permissions

What is the recommended practice for the usage of these RBAC files?

If an operator is installed via the OLM are these RBAC files used to permit all users to create instances of the CRD?

Thanks,
Michael

[Eric Stroczynski]

These RBAC manifests define the equivalent of un-aggregated user-facing roles for editing (r/w) and viewing (r) privileges for CRs.

If you'd like users to be able to CRUD a CR, bind their service account/user profile to the editor role; for read-only access, bind to the viewer role.

This should be documented in kubebuilder's docs and linked in operator-sdk's (create an issue in the kubebuilder repo if you can).

Thanks for bringing this up.

--
You received this message because you are subscribed to the Google Groups "Operator Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to operator-framew...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/operator-framework/441c3f45-e7e5-7ebc-0ba1-2077b78f7b2d%40redhat.com.

--

Eric Stroczynski

Senior Software Engineer
Operator SDK Team
Red Hat Inc. San Francisco Office