Description of problem:
After updating OpenShift Logging to version 4.5 the customer is unable to create 'app' index pattern if permissions on the project are granted via group. In case it's granted via RoleBinding for the user directly it works as expected.

The following does document the user experience.

----------
Definitions before Testing
----------
$ oc -n xyz123-dev-ACME-de get rolebindings
NAME                                        ROLE                               AGE
admin                                       ClusterRole/admin                  33d
edit                                        ClusterRole/edit                   33d
hans.muster   ClusterRole/edit                   30d
system:deployers                            ClusterRole/system:deployer        33d
system:image-builders                       ClusterRole/system:image-builder   33d
system:image-pullers                        ClusterRole/system:image-puller    33d
view                                        ClusterRole/view                   33d
----------
$ oc -n xyz123-dev-ACME-de get rolebindings admin -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  creationTimestamp: "2020-10-02T05:02:05Z"
  name: admin
  namespace: xyz123-dev-ACME-de
  resourceVersion: "336018672"
  selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/xyz123-dev-ACME-de/rolebindings/admin
  uid: 9ca3bd64-787f-435d-a4a4-4976106a4aa4
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin
subjects:
- kind: ServiceAccount
  name: abc456
  namespace: abc123-OCP-cc
- kind: ServiceAccount
  name: mad
  namespace: accounts-prod-ACME-de
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: administrator__it-life_dev__ACME country kjhg
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: kag_xyz_non_prod__ACME country kjhg
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: subscription-owner__it-life_dev__ACME country kjhg
----------
$ oc get group "kag_xyz_non_prod__ACME country kjhg" -o yaml
apiVersion: user.openshift.io/v1
kind: Group
metadata:
  creationTimestamp: "2020-06-10T11:36:16Z"
  labels:
    sub-reg/id: 160a235479c3488699661dfe6db6fa98
  name: kag_xyz_non_prod__ACME country kjhg
  resourceVersion: "149240770"
  selfLink: /apis/user.openshift.io/v1/groups/kag_xyz_non_prod__ACME+country+kjhg
  uid: 95c8f81a-0c25-4279-8be3-dd13316a5e05
users:
- john.done
- foo.bar
- hans.muster
--------------------
Test Steps
----------
Step-1
Using MY Kibana I've successfully verified, that my Kibana displays the logs of both running pods 'xyz123-dev-ACME-abc-7b9fcd8c5-xhwp8' and 'xyz123-dev-ACME-qwe-5cb84b575d-nw525'.
----------
Step-2
In the OpenShift console the user navigated to the tab 'Logs' of the view 'Pod details' of the pod 'xyz123-dev-ACME-abc-7b9fcd8c5-xhwp8'.
The logs stream (lasst 1000 lines) was displayed
----------
Step-3
The user clicked on "Show in Kibana".
Kibana opened (in a new browser tab), landed on the page "Management > Create index pattern" and searched for matching indices WITHOUT success. It stopped after ~30 seconds with no results.
----------
Step-4
The user closed the Kibana browser tab.
----------
Step-5
I've executed on OpenShift CLI..$ oc -n xyz123-dev-ACME-de adm policy add-role-to-user admin user.example
$ oc -n xyz123-dev-ACME-de get rolebindings
NAME                                        ROLE                               AGE
admin                                       ClusterRole/admin                  33d
admin-0                                     ClusterRole/admin                  50m
edit                                        ClusterRole/edit                   33d
hans.muster   ClusterRole/edit                   30d
system:deployers                            ClusterRole/system:deployer        33d
system:image-builders                       ClusterRole/system:image-builder   33d
system:image-pullers                        ClusterRole/system:image-puller    33d
view                                        ClusterRole/view                   33d
$ oc -n xyz123-dev-ACME-de get rolebindings admin-0 -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  creationTimestamp: "2020-11-04T14:38:40Z"
  managedFields:
  - apiVersion: rbac.authorization.k8s.io/v1
    fieldsType: FieldsV1
    fieldsV1:
      f:roleRef:
        f:apiGroup: {}
        f:kind: {}
        f:name: {}
      f:subjects: {}
    manager: oc
    operation: Update
    time: "2020-11-04T14:38:40Z"
  name: admin-0
  namespace: xyz123-dev-ACME-de
  resourceVersion: "409567147"
  selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/xyz123-dev-ACME-de/rolebindings/admin-0
  uid: 36e0645e-2773-4229-984a-78897cf21be1
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: user.example
----------
Step-6
The user clicked again on "Show in Kibana".
Kibana opened (in a new browser tab), landed on the page "Management > Create index pattern" and successfully searched for matching indices.
The user could create an index pattern 'app-*'.
Kibana afterwards displayed the logs of the pod 'xyz123-dev-ACME-abc-7b9fcd8c5-xhwp8'.
----------
Step-7
The user repeated the appropriate steps accordingly for the second pod 'xyz123-dev-ACME-qwe-5cb84b575d-nw525'. Kibana also displayed the logs of the second pod.

Version-Release number of selected component (if applicable):

 - Elasticsearch 4.5.0-202010222033.p0
 - Cluster Logging 4.5.0-202010221357.p0

How reproducible:

 - Always


Steps to Reproduce:
1. Grant access to projects via Group to users
2. Check if 'app' index pattern can be created in Kibana with those users

Actual results:

Kibana is reporting that it's unable to find `elasticsearch` data with "Couldn't find any Elasticsearch data"

Expected results:

User should be able to create the 'app' index pattern in Kibana upon first logging and when the application is already running and sending logs

Additional info:

As highlighted above, if the user is granted permissions without group (directly with the user) it works as expected.