fix(kiali-server): don't create unused ClusterRole

[capuche2412]

PR to solve kiali/kiali#7357

[jmazzitelli]

anonymous mode can still be used with view_only_mode=true or false (in fact, I think many people use it with true, but there is no restriction).

I don't think auth.strategy setting should affect which role is created.

Can you explain the thinking behind checking for anonymous mode?

[capuche2412]

I get your point.
The goal is to have the same behavior with the roleBinding.
So if the roleBinding is set to viewer role, the viewer role is created (same for full rights role)

[jmazzitelli]

Ah, right. I remember this now.

• Kiali SA should use view-only role unless using anonymous strategy kiali#5611.

[jmazzitelli]

see my previous comment about auth.strategy.

dismissing change-request - if not anonymous, the Kiali SA will always be view-only. Only when using anonymous would the SA ever possibly be read-write

[jmazzitelli]

Here's a quick test to see things working. Run "helm template" with these combinations of settings - the first three should result in the kiali-viewer Role being created and used in the RoleBinding whose name is also kiali-viewer. The last should not have any kiali-viewer resource generated or used.

1. deployment.view_only_mode=false , auth.strategy=token
2. deployment.view_only_mode=true , auth.strategy=token
3. deployment.view_only_mode=true , auth.strategy=anonymous
4. deployment.view_only_mode=false , auth.strategy=anonymous

$ helm template --set deployment.view_only_mode=false --set auth.strategy=token _output/charts/kiali-server-*.tgz | grep "kiali-viewer"
  name: kiali-viewer
  name: kiali-viewer
  name: kiali-viewer

$ helm template --set deployment.view_only_mode=true --set auth.strategy=token _output/charts/kiali-server-*.tgz | grep "kiali-viewer"
  name: kiali-viewer
  name: kiali-viewer
  name: kiali-viewer

$ helm template --set deployment.view_only_mode=true --set auth.strategy=anonymous _output/charts/kiali-server-*.tgz | grep "kiali-viewer"
  name: kiali-viewer
  name: kiali-viewer
  name: kiali-viewer

$ helm template --set deployment.view_only_mode=false --set auth.strategy=anonymous _output/charts/kiali-server-*.tgz | grep "kiali-viewer"
<empty output>

That last one will show a different behavior from the current helm chart. Because both roles are created today, that last one will result in a single "name: kiali-vewer" line (that's the Role that is created but not used).

You can also examine the output of one of the first three commands to see that no Role is created with the name "kiali" that has the write permissions. A quick way to see this is to grep for "ClusterRole" and see that only one is created now with this PR, but today's helm charts create two roles:

This PR results in:

$ helm template --set deployment.view_only_mode=true --set auth.strategy=token _output/charts/kiali-server-*.tgz | yq | grep '^kind: ClusterRole'
kind: ClusterRole
kind: ClusterRoleBinding

but master build (today's helm chart) results in:

$ helm template --set deployment.view_only_mode=true --set auth.strategy=token _output/charts/kiali-server-*.tgz | yq | grep '^kind: ClusterRole'
kind: ClusterRole
kind: ClusterRole
kind: ClusterRoleBinding

[jmazzitelli]

lgtm. reviewed code and tested (see test procedure I used in earlier comment).

[jmazzitelli]

I did a quick check of the hack/istio/multicluster/kiali-prepare-remote-cluster.sh script which uses the server helm chart to prepare remote cluster secrets in a multi-cluster environment, and it should still work. The relevant code is here, and this does not look like it requires the old behavior of getting both roles created - it only looks for role or role-viewer depending on the view_only_mode setting passed in by the user.