tutunannan
commented
4 months ago There is a good article on this subject that details some typical scenarios, best practices, and recommendations. https://medium.com/@nathanpbrophy/olm-and-operator-permissions-declassified-54cd1465f2b4
It recommends a pattern for Operators to consume permissions on a cluster, and how a user can determine what permissions an Operator can perform.
Cluster Admins:
- Define an Operator Group with a Service Account that limits permissions to only those the Operator needs
- Install Operators in the minimum scope required to perform the task
Operator Developers:
- Defer as many permissions to the Operator as possible (limit the number of permissions the Operand i.e., application, needs)
- Do not put Operand permissions or bindings to permissions in the Operator bundle
- Limit the amount of cluster scoped permissions used by the Operator or Operand
This article mentions that there are some valid use cases for injecting Operand permissions into the bundle of the Operator, but those use cases are highly specialized. In general, injecting Operand permissions into the bundle for the Operator is an anti-practice, because the Operand is not generally an extension of the control-plane. It is recommended to minimize the amount of Kubernetes permissions an Operand needs and defer the interaction with the control-plane to the Operator.
Desc
Operator is managed and installed by OLM. According to the OLM specification, when an OLM installation mode is used to install operator, the rights of operator are restricted by OLM.
For example, if the installation mode is selected as the owner namespace, or a namespace, then the operator should only manage CR resources for the corresponding namespace. However, this situation violates the functional responsibilities of the operator itself. The operator itself should listen for more content to meet the needs of the user.
Q&A
Based on the above, several issues need to be discussed: