[operator] perform true "can_i" check to confirm the operator has correct permissions

[jmazzitelli]

If a Kiali CR setting deployment.accessible_namespaces is set to ["**"] then the operator needs permissions to create and delete ClusterRole and ClusterRoleBinding resources. The operator will check that it has these permissions and abort the Kiali installation if it does not. We do this because a user may have opted to not install the operator with those "super-power" permissions (some users may not want to give the operator service account permissions to create clusterroles/bindings - see how they can do that here) - in that case, the user cannot specify ["**"] as the value to deployment.accessible_namespaces.

The proper way for the operator to check to see if it has the necessary permissions would be for the operator to create a SelfSubjectAccessReview and look at the resulting status field to determine if it has those permissions - this is what I call a true "can_i" check as documented here.

In Ansible, the way you should be able to do this is via something like the following (this checks for create-clusterroles permission; an analogous one would be performed for create-clusterrolebindings permission):

- name: can_i create clusterroles test
  register: can_i_create_clusterroles
  k8s:
    state: present
    definition:
      apiVersion: authorization.k8s.io/v1
      kind: SelfSubjectAccessReview
      spec:
        resourceAttributes:
          group: rbac.authorization.k8s.io
          resource: clusterroles
          verb: create

Looking at the resulting can_i_create_clusterroles object (specifically its status field) will tell you if that permission exists or not.

However, there is a bug in the kubernetes collection task k8s that causes that mechanism to not work. Therefore, today the operator performs a hack introduced by PR kiali/kiali-operator#137 - it actually creates (or at least attempts to create) a dummy ClusterRole and dummy ClusterRoleBinding. If the creation is successful, the operator knows it has the proper permissions; if the creation for either one of those fails, the operator knows it does not have the proper permissions and aborts the installation of Kiali. The operator will immediately delete any of those two dummy resources that it managed to successfully create. The code is in kiali-deploy/tasks/main.yml - do a search for kiali-dummy and you'll see it.

Of course, this is a hack. We should be using a true "can-i" check. So this issue is to document the fact that we want to wait for that bug to be fixed and when it is fixed we want to go in and remove that hack and replace it with a true "can_i" check using the resource SelfSubjectAccessReview as explained above.

[jmazzitelli]

The kubernetes collections API has been updated and now fixes that bug. See: ansible-collections/community.kubernetes#237

We just need to put a newer version of the collection into our operator image. Would require some additions to the Dockerfile.

[jmazzitelli]

This should be the list of tasks to replace the current hack - though currently I can't get it to work with the latest 1.1.1 of the community.kubernetes library:

- name: Determine if the operator can support accessible_namespaces=** - can_i create clusterroles
  register: can_i_create_clusterroles
  ignore_errors: yes
  community.kubernetes.k8s:
    state: present
    definition:
      apiVersion: authorization.k8s.io/v1
      kind: SelfSubjectAccessReview
      spec:
        resourceAttributes:
          group: rbac.authorization.k8s.io/v1
          resource: clusterroles
          verb: create
  when:
  - '"**" in kiali_vars.deployment.accessible_namespaces'

- name: Determine if the operator can support accessible_namespaces=** - can_i create clusterrolebindings
  register: can_i_create_clusterrolebindings
  ignore_errors: yes
  community.kubernetes.k8s:
    state: present
    definition:
      apiVersion: authorization.k8s.io/v1
      kind: SelfSubjectAccessReview
      spec:
        resourceAttributes:
          group: rbac.authorization.k8s.io/v1
          resource: clusterrolebindings
          verb: create
  when:
  - '"**" in kiali_vars.deployment.accessible_namespaces'
  - can_i_create_clusterroles is successful

- fail:
    msg: "The operator cannot support deployment.accessible_namespaces set to '**' because it does not have permissions to create clusterroles"
  when:
  - '"**" in kiali_vars.deployment.accessible_namespaces'
  - can_i_create_clusterroles is not successful

- fail:
    msg: "The operator cannot support deployment.accessible_namespaces set to '**' because it does not have permissions to create clusterrolebindings"
  when:
  - '"**" in kiali_vars.deployment.accessible_namespaces'
  - can_i_create_clusterrolebindings is not successful

[jmazzitelli]

This requires the operator to be given "list" permission to "SelfSubjectAccessReview".
But even after we do this, it will require additional packaging to pick up the latest community.kubernetes since the ansible base image doesn't have it yet.
Going to wait more before attempting to implement this.

[jmazzitelli]

If we implement this, it means we removed the hack of creating the dummy roles - in that case we can turn back on dependent resource watching. We turned that off because the hack causes infinite reconciliation loops due to the hack.

[jmazzitelli]

when the new collectons.kubernetes library is available, we can implement this.

[jmazzitelli]

And I still think we can't do this yet... it looks like even Ansible Operator SDK 4.7.0, 4.8.0, and 4.9.0 do not have the latest community.kubernetes that we need:

$ docker run -it --rm  --entrypoint ''  quay.io/openshift/origin-ansible-operator:4.7.0 cat /opt/ansible/.ansible/collections/ansible_collections/community/kubernetes/MANIFEST.json | grep version
  "version": "0.11.1",

It has 0.11.1 and we need at least 1.1 (see the commit where the bug fix went in - you can see it went in 1.1.0 - ansible-collections/community.kubernetes@0f3fef9)

I did try it with PRs kiali/helm-charts#70 and kiali/kiali-operator#307 and I got the same error. Oh well. We'll wait another couple months... at least we have the draft PRs to show how it should be done.

[jmazzitelli]

"4.8" now has 1.2.1:

docker run -it --rm  --entrypoint ''  quay.io/openshift/origin-ansible-operator:4.8 cat /opt/ansible/.ansible/collections/ansible_collections/community/kubernetes/MANIFEST.json | grep version
  "version": "1.2.1",

"4.7" is still at 0.11. Looks like we'll need to bump up to get this.

docker run -it --rm  --entrypoint ''  quay.io/openshift/origin-ansible-operator:4.7 cat /opt/ansible/.ansible/collections/ansible_collections/community/kubernetes/MANIFEST.json | grep version
  "version": "0.11.1",

[jmazzitelli]

This will help: #4094

But realize that downstream releases of ansible operator sdk are only up to 4.7 - we should wait until 4.8 is released.

[jmazzitelli]

we can do this now as even the redhat registry published the 4.8 sdk: https://catalog.redhat.com/software/containers/openshift4/ose-ansible-operator/5cdc9a53bed8bd5717d6345e?tag=all

$ podman run -it --rm --entrypoint '' registry.redhat.io/openshift4/ose-ansible-operator:v4.8 cat /opt/ansible/.ansible/collections/ansible_collections/community/kubernetes/MANIFEST.json | grep version
  "version": "1.2.1",

And quay:

$ podman run -it --rm --entrypoint '' quay.io/openshift/origin-ansible-operator:4.8 cat /opt/ansible/.ansible/collections/ansible_collections/community/kubernetes/MANIFEST.json | grep version
  "version": "1.2.1",

[jmazzitelli]

To test, build and install using these PRs:

• add true can-i check to make sure the operator has the permissions it needs kiali-operator#307
• add true can-i check to make sure the operator has the permissions it needs helm-charts#70

The steps to test this are simple and documented here: kiali/kiali-operator#307 (comment)