-
Notifications
You must be signed in to change notification settings - Fork 24
Description
What is your persona?
I'm an application developer that is designing a POC of an open-source application that integrates crane to export the configuration of an application.
What is your story / use case?
As a user of the crane export command, I want to include all the non-namespaced (e.g. cluster scoped) RBAC resources that are linked to the ServiceAccount defined in the exported namespace(s), so that the generated manifests can be deployed on a new environment with no further manual operations.
Using an optional flag to the crane export command, like --cluster-scoped-rbac (defaulted to "false" to disable the requested feature), at the end of the crane export-transform-apply pipeline, we can generate a complete and consistent set of manifests that can be deployed on any environment without any manual intervention to setup the RBAC aspects.
Do you have a suggestion for implementation?
I would implement this as an optional flag in the crane core module, since the export command does not support the concept of plugin.
Since we want only some of these cluster-scoped resources, we should define somewhere the list of managed types (e.g., ClusterRole, ClusterRoleBinding and, in case of OpenShift cluster, also SecurityContextConstraints) and load them only after all the configured namespaces have been exported, to discard those that are not connected to any of the exported ServiceAccount (maybe a cache can be required to store all of them, or at least their namespace and name pairs).
Once selected, those manifests can be stored in a dedicated folder, with a name that can't match a namespace name, like _cluster.
While the contributors review the issue, I would start developing the feature to validate the proposed solution.