fabric8io / openshift-elasticsearch-plugin

Apache License 2.0
27 stars 21 forks source link

kibana IndexPattern disable project uid #177

Closed Gallardot closed 2 years ago

Gallardot commented 5 years ago

The tribes feature allows a tribe node to act as a federated client across multiple clusters. The general network topology is as follows: es

We have Multiple openshift-elasticsearch clusters. We want to query app logger in any one kibana. The network topology is as follows.

oses

We have the same project on multiple clusters,but the same project don't have the same uid. kibana IndexPattern format is as the project.project_name.project_UID. Project X on cluster Y the kibana IndexPattern look like this project.X.87654321-4f9f-11e9-91cd-000c29052923. . Project X on cluster Z the kibana IndexPattern look like this project.X.12345678-1234-1234-1234-000c29052923.* .

If we use project.X.* as the IndexPattern, we can query project X's logs in all cluster through tribenode. So, I think we need a configuration to decide whether to disable the project UID on kibana IndexPattern .We have do some work for this

If we don't do this, we should sync all project info from one openshift cluster to other cluster in this plugin. we don’t think is a good idea.

Any Suggestions? Thank you

richm commented 5 years ago

If we use project.X.* as the IndexPattern, we can query project X's logs in all cluster through tribenode.

How do you know that all users in project X in cluster A can view all of the logs in project X in cluster B?

Gallardot commented 5 years ago

oses

We built the above system architecture. The system information is as follows:

OpenShift Master:v3.11.0+cca69c5-73
Kubernetes Master:v1.11.0+d4cacc0
OpenShift Web Console:v3.11.0+ea42280
elasticsearch:origin-logging-elasticsearch5:v3.11.0
Kibana:origin-logging-kibana5:v3.11.0

The tribe node also use origin-logging-elasticsearch5:v3.11.0.

We sync the Secrets "logging-curator"、"logging-elasticsearch"、"logging-fluentd"、"logging-kibana" from Cluster A to Cluster B.

We create the same project X and the same user A1 in Cluster A and Cluster B.

After that,Our user can query app logs on kibana through tribenode.

16_32_07__05_08_2019 result from cluster A

16_33_36__05_08_2019

result from cluster B

The kibana Indexpattern is auto create by openshift-elasticsearch-plugin. So, we want to kibana Indexpattern can disable the project UID in openshift-elasticsearch-plugin.

@richm we have post a patch on our branch. please review.

richm commented 5 years ago

So, we want to kibana Indexpattern can disable the project UID in openshift-elasticsearch-plugin.

Ok. I'm generally in favor of this as long as it causes no regressions in either performance or security.

@richm we have post a patch on our branch. please review.

which branch?

jcantrill commented 5 years ago

This UUID was introduced into the index pattern because there were cases where searches would match both a live project and deleted project as represented in ES. There is no way to guarantee a user had access to the logs from the deleted namespace and the query result would return 403 leaving a confused user. One way you could resolve your particular issue is to introduce configuration and a strategy to control the index pattern creation behavior. Ref: https://github.com/fabric8io/openshift-elasticsearch-plugin/blob/master/src/main/java/io/fabric8/elasticsearch/plugin/kibana/KibanaUtils.java#L110

Gallardot commented 5 years ago

@richm @jcantrill
I have post a pr #178

I do some test on our cluster.

We also make a strategy to control RolesSync into seachguard :ProjectRolesSyncStrategy and UserRolesSyncStrategy

jcantrill commented 5 years ago

I think the path you are going down is making it more complicated by adding conditionals where not needed. This https://github.com/fabric8io/openshift-elasticsearch-plugin/blob/master/src/main/java/io/fabric8/elasticsearch/plugin/kibana/KibanaUtils.java#L110 file controls the formatting. Why not inject a strategy for formatting the pattern into the util which is already used else where? Our default scenario is unlikely to use this feature so I would propose to seed the patterns as project.logan.* and skip the ones with UID all together