install kiali using the new kiali operator#13299
install kiali using the new kiali operator#13299jmazzitelli wants to merge 1 commit intoistio:release-1.1from
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: jmazzitelli If they are not already assigned, you can assign the PR to them by writing The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
This works fine - however, when deleting by either removing the istio-system namespace via "kubectl delete namespace" or "helm delete", the namespace hangs in the Terminating state because the operator is deleted before it gets a chance to run its delete workflow. This leaves a finalizer flag in the kiali CR. I'm trying to figure out how to work around this. |
|
@jmazzitelli: The following tests failed, say
DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
|
I asked about how to work around this "delete" issue on the discuss forum here: https://discuss.istio.io/t/how-will-operators-be-integrated-into-the-helm-charts/1899 |
| - '*' | ||
| - apiGroups: ["rbac.authorization.k8s.io"] | ||
| resources: | ||
| - clusterrolebindings |
There was a problem hiding this comment.
Does that allow the Kiali operator to create arbitrary roles and bindings on cluster level? That would allow privilege escalation at its best.
|
@jmazzitelli if Kiali is observability project according what I read on |
|
@sbezverk Kiali provides more than a mere read-only view of the mesh (though you can install it with a view-only permissions if you want that - the new operator now provides a "view_only_mode" setting) - it provides things like allowing users to re-adjust destination rules for balancing traffic and things like that - hence why you see those perms. These types of perms are already granted in the current kiali helm charts. See these links for some examples. I'm not sure what documentation and demo videos we have available that show this functionality - I'm cc'ing @lucasponce - he should be able to provide more details if you wish kiali/kiali-ui#1108 As for these perms, these are required for the Kiali Operator to be able to install Kiali (these are requirements, for example, to allow the Operator to create the kiali deployment, service, roles, etc.). |
@jmazzitelli I think these permissions are problematic for a default Istio installation, especially the cluster role and cluster role binding. That is the key to the cluster admin door, isn't it? |
|
@sbezverk as @jmazzitelli has presented, next step in the Observability goal of Kiali is to provide "actions" on the "observed" entities. Not only to detect where a problem is located/identified but to provide meaninful high level "actions" on those. In that sense, Kiali is able to create and modify Istio resources from a high level perspective, hiding the complexity of Gateways/VirtualServices/DestinationRules to the user. It's a TODO action to update properly the kiali.io site, but that's on of the important features of Kiali, so that's reason that kiali should be able to at least to operate on the same namespaces where a user could also create/modify those configurations. We provided two different service accounts (one with the modify verbs) and other with read-only permissions, in case that a user doesn't want to enable kiali for these actions. |
|
Based on the discussion at https://discuss.istio.io/t/how-will-operators-be-integrated-into-the-helm-charts/1899/2 I'm going to close this PR. |
This installs Kiali using the new Kiali Operator.