RBAC should be auto-generated #1105
Comments
|
@skitt @SteveMattar shall this be an item for 0.9.0? sounds risky to me. |
|
I’ve got a patch in progress for this, but it is indeed somewhat risky (although the code generates files we can compare with the existing setup, so it’s easy enough to verify). I’ve moved it to 0.10. |
|
I agree let's wait with this |
This allows RBAC settings to be declared as close as possible to their point of use, which means that, as functions are added and deleted, permissions will be adjusted "automatically" and we'll avoid keeping no-longer-needed permissions. As generated by the operator SDK, the operator ends up with only cluster roles, but this makes sense since the operator is supposed to be able to act in any namespace. Fixes: submariner-io#1105 Signed-off-by: Stephen Kitt <[email protected]>
This allows RBAC settings to be declared as close as possible to their point of use, which means that, as functions are added and deleted, permissions will be adjusted "automatically" and we'll avoid keeping no-longer-needed permissions. As generated by the operator SDK, the operator ends up with only cluster roles, but this makes sense since the operator is supposed to be able to act in any namespace. Fixes: submariner-io#1105 Signed-off-by: Stephen Kitt <[email protected]>
This allows RBAC settings to be declared as close as possible to their point of use, which means that, as functions are added and deleted, permissions will be adjusted "automatically" and we'll avoid keeping no-longer-needed permissions. As generated by the operator SDK, the operator ends up with only cluster roles, but this makes sense since the operator is supposed to be able to act in any namespace. Fixes: submariner-io#1105 Signed-off-by: Stephen Kitt <[email protected]>
This allows RBAC settings to be declared as close as possible to their point of use, which means that, as functions are added and deleted, permissions will be adjusted "automatically" and we'll avoid keeping no-longer-needed permissions. As generated by the operator SDK, the operator ends up with only cluster roles, but this makes sense since the operator is supposed to be able to act in any namespace. Fixes: submariner-io#1105 Signed-off-by: Stephen Kitt <[email protected]>
This allows RBAC settings to be declared as close as possible to their point of use, which means that, as functions are added and deleted, permissions will be adjusted "automatically" and we'll avoid keeping no-longer-needed permissions. As generated by the operator SDK, the operator ends up with only cluster roles, but this makes sense since the operator is supposed to be able to act in any namespace. Fixes: submariner-io#1105 Signed-off-by: Stephen Kitt <[email protected]>
This allows RBAC settings to be declared as close as possible to their point of use, which means that, as functions are added and deleted, permissions will be adjusted "automatically" and we'll avoid keeping no-longer-needed permissions. As generated by the operator SDK, the operator ends up with only cluster roles, but this makes sense since the operator is supposed to be able to act in any namespace. Fixes: submariner-io#1105 Signed-off-by: Stephen Kitt <[email protected]>
nyechiel
added
the
open-cluster-management
|
The kustomize part is handled in this patch: #1375 |
|
This issue has been automatically marked as stale because it has not had activity for 60 days. It will be closed if no further activity occurs. Please make a comment if this issue/pr is still valid. Thank you for your contributions. |
|
@skitt Do you have any pointers about how this should be done? |
|
The relevant section in the Operator SDK documentation is https://sdk.operatorframework.io/docs/building-operators/golang/operator-scope/#restricting-roles-and-permissions The kubebuilder reference is https://book.kubebuilder.io/reference/markers/rbac.html See skitt#16 where I started working on this a while back — my process then was to compare the generated RBAC with the RBAC we had in our YAML files, determine whether a missing permission was significant, and add the corresponding annotation. |
|
See operator-framework/operator-sdk#6100 for namespace permissions instead of cluster permissions. |
|
I should stop beating my head against this and ask...what about the non-operator roles? I went through some ideas that turned out obviously-in-retrospect bad, like annotating some calls with extra permissions to try to cover them or cloning the other repos during generation. |
Still not sure what to do about roles that are currently hosted in the operator repo but with code-to-annotate in other repos, how to connect them to the automated generation. |
We should generate the RBAC declarations from code (see the
TODOincontrollers/submariner/broker_controller.go). The resulting YAML files could also be re-used for the operator bundle, and the RBAC-declaration code inpkg/broker/rbac.gowould no longer be necessary.The text was updated successfully, but these errors were encountered: