Hello,
our company thinking about buying ROR plugin. We need to meet some requirements. Could you please tell me whether:
Vasek
Hi @vaclav_sulc!
The first question is a yes, see the full guide about Azure ADFS.
About ECK, we would need to create PoC. Let me discuss this with @coutoPL, because it can be a good show off demo for the product in general.
IIRC when we tried something similar in the past we had issues with document level security (filter rule) because we required ROR to be started in proxy mode. But I have to check if it’s still the case.
@vaclav_sulc we are going to create a PoC: minikube + ECK + ROR and see if there are any issues. We let you know about the progress
@coutoPL what’s the latest with the ECK PoC?
Integration with ES 7.16.0 is a much more important thing ATM. I’m going to get back to this topic as soon as I finish.
But I can say that I solved an important blocker and it looks like I’m very close to making ES ROR work with ECK. The next thing to check will be the ROR KBN plugin.
Very interested to use ROR with ECK 7.16.0. Thanks for futur integration.
EDIT: I saw a few demos and I think I can answer myself here: ECK makes it so much easier to maintain a single multi-node ELK cluster. Rolling updates to new Elastic stack versions, auto scaling, etc.
I really think we should not only support ECK, but use it also for daily development and integration tests.
@Romain to be honest, me too. Quite a few customers have requested for ECK interop.
There is one thing I didn’t fully understand though (and maybe you can answer).
ROR Enterprise comes with pretty good segregation capabilities both on data access and Kibana configuration, without the need to instantiate multiple clusters for multiple tenancies.
And this introduces great savings in terms of compute resources: everyone can work with a large, capable ELK cluster instead of having their own tiny cluster.
But now I see customers (even Enterprise customers) asking for ECK, which is basically a GUI for automatic creation of multiple ELK clusters in Kubernetes.
Saving in compute resources introduced by ROR Enterprise are less than the license price?
There’s a stricter requirement in physically separating data from different tenants?
You already use Kubernetes, and ECK is seen as a clean way to install the single, ROR-powered multi-tenant cluster?
Something else (comment please!)0 voters
Hi Guys,
we have a working PoC ECK + ROR. We’re going to improve our solution now, write docs and create a demo. The March release will have ECK support for sure!
Hi There,
We would like to try the ROR on ECK, Any update on the POC?
PoC stage is done. We proved that we’re able to run ROR with ECK. Sadly, the final solution is not ready yet. We will notify you when it’s done. But you can check the PoC if you wish
Hi @coutoPL ,
When I am trying to run the PoC, in the Kubernetes cluster, I am seeing this Error. Any idea how can we fix this? The following error occurs in the Kibana.
FATAL Error: [config validation of [elasticsearch].serviceAccountToken]: serviceAccountToken cannot be specified when “username” is also set.
I don’t think the PoC is working as expected. The following API should work in order to create index patterns in Kibana but it is giving the error.
Please suggest.
curl -k -u admin:container ‘https://localhost:9200/_field_caps?pretty&fields=message’
{
“error” : {
“root_cause” : [
{
“type” : “security_exception”,
“reason” : “action [indices:data/read/field_caps[n]] is unauthorized for user [_xpack] with roles [_xpack], this action is granted by the index privileges [view_index_metadata,manage,read,all]”
}
],
“type” : “security_exception”,
“reason” : “action [indices:data/read/field_caps[n]] is unauthorized for user [_xpack] with roles [_xpack], this action is granted by the index privileges [view_index_metadata,manage,read,all]”,
“caused_by” : {
“type” : “illegal_argument_exception”,
“reason” : “the action indices:data/read/field_caps[n] does not support wildcards; the provided index expression(s) [*] are not allowed”
}
},
“status” : 403
}
The Debug logs are:
{“type”: “server”, “timestamp”: “2022-05-28T15:58:48,586Z”, “level”: “DEBUG”, “component”: “i.n.h.s.SslHandler”, “cluster.name”: “quickstart”, “node.name”: “quickstart-es-default-0”, “message”: “[id: 0xbfdf5ef8, L:/[0:0:0:0:0:0:0:1]:9200 - R:/[0:0:0:0:0:0:0:1]:60680] HANDSHAKEN: protocol:TLSv1.3 cipher suite:TLS_AES_256_GCM_SHA384”, “cluster.uuid”: “-wqFgRwWSW2y52F0eoJT-Q”, “node.id”: “9EhO7lBlTFKm03jvE31flg” }
{“type”: “server”, “timestamp”: “2022-05-28T15:58:48,587Z”, “level”: “DEBUG”, “component”: “t.b.r.e.h.r.c.t.IndicesReplaceableEsRequestContext”, “cluster.name”: “quickstart”, “node.name”: “quickstart-es-default-0”, “message”: “[889922824-2024090004#2355] Discovered indices: ", “cluster.uuid”: “-wqFgRwWSW2y52F0eoJT-Q”, “node.id”: “9EhO7lBlTFKm03jvE31flg” }
{“type”: “server”, “timestamp”: “2022-05-28T15:58:48,587Z”, “level”: “DEBUG”, “component”: “t.b.r.a.l.AccessControlLoggingDecorator”, “cluster.name”: “quickstart”, “node.name”: “quickstart-es-default-0”, “message”: “checking request: 889922824-2024090004#2355”, “cluster.uuid”: “-wqFgRwWSW2y52F0eoJT-Q”, “node.id”: “9EhO7lBlTFKm03jvE31flg” }
{“type”: “server”, “timestamp”: “2022-05-28T15:58:48,588Z”, “level”: “DEBUG”, “component”: “t.b.r.a.b.r.AuthKeyRule”, “cluster.name”: “quickstart”, “node.name”: “quickstart-es-default-0”, “message”: “Attempting Login as: admin rc: 889922824-2024090004#2355”, “cluster.uuid”: “-wqFgRwWSW2y52F0eoJT-Q”, “node.id”: “9EhO7lBlTFKm03jvE31flg” }
{“type”: “server”, “timestamp”: “2022-05-28T15:58:48,588Z”, “level”: “DEBUG”, “component”: “t.b.r.a.b.Block”, “cluster.name”: “quickstart”, “node.name”: “quickstart-es-default-0”, “message”: "\u001B[33m[::KIBANA-SRV::] the request matches no rules in this block: { ID:889922824-2024090004#2355, TYP:FieldCapabilitiesRequest, CGR:N/A, USR:admin (attempted), BRS:true, KDX:null, ACT:indices:data/read/field_caps, OA:127.0.0.1/32, XFF:null, DA:::1/32, IDX:, MET:GET, PTH:/_field_caps, CNT:<N/A>, HDR:Accept=/, Authorization=, Host=localhost:9200, User-Agent=curl/7.68.0, content-length=0, HIS:[::KIBANA-SRV::-> RULES:[auth_key->false] RESOLVED:[indices=]], } \u001B[0m", “cluster.uuid”: “-wqFgRwWSW2y52F0eoJT-Q”, “node.id”: “9EhO7lBlTFKm03jvE31flg” }
{“type”: “server”, “timestamp”: “2022-05-28T15:58:48,588Z”, “level”: “DEBUG”, “component”: “t.b.r.a.b.r.AuthKeyRule”, “cluster.name”: “quickstart”, “node.name”: “quickstart-es-default-0”, “message”: “Attempting Login as: admin rc: 889922824-2024090004#2355”, “cluster.uuid”: “-wqFgRwWSW2y52F0eoJT-Q”, “node.id”: “9EhO7lBlTFKm03jvE31flg” }
{“type”: “server”, “timestamp”: “2022-05-28T15:58:48,589Z”, “level”: “DEBUG”, “component”: “t.b.r.a.b.Block”, “cluster.name”: “quickstart”, “node.name”: “quickstart-es-default-0”, “message”: "\u001B[33m[DEFAULT KIBANA USER] the request matches no rules in this block: { ID:889922824-2024090004#2355, TYP:FieldCapabilitiesRequest, CGR:N/A, USR:admin (attempted), BRS:true, KDX:null, ACT:indices:data/read/field_caps, OA:127.0.0.1/32, XFF:null, DA:::1/32, IDX:, MET:GET, PTH:/_field_caps, CNT:<N/A>, HDR:Accept=/, Authorization=, Host=localhost:9200, User-Agent=curl/7.68.0, content-length=0, HIS:[DEFAULT KIBANA USER-> RULES:[auth_key->false] RESOLVED:[indices=]], } \u001B[0m", “cluster.uuid”: “-wqFgRwWSW2y52F0eoJT-Q”, “node.id”: “9EhO7lBlTFKm03jvE31flg” }
{“type”: “server”, “timestamp”: “2022-05-28T15:58:48,589Z”, “level”: “DEBUG”, “component”: “t.b.r.a.b.r.AuthKeyRule”, “cluster.name”: “quickstart”, “node.name”: “quickstart-es-default-0”, “message”: “Attempting Login as: admin rc: 889922824-2024090004#2355”, “cluster.uuid”: “-wqFgRwWSW2y52F0eoJT-Q”, “node.id”: “9EhO7lBlTFKm03jvE31flg” }
{“type”: “server”, “timestamp”: “2022-05-28T15:58:48,589Z”, “level”: “DEBUG”, “component”: “t.b.r.a.b.Block”, “cluster.name”: “quickstart”, “node.name”: “quickstart-es-default-0”, “message”: "\u001B[33m[PROBE] the request matches no rules in this block: { ID:889922824-2024090004#2355, TYP:FieldCapabilitiesRequest, CGR:N/A, USR:admin (attempted), BRS:true, KDX:null, ACT:indices:data/read/field_caps, OA:127.0.0.1/32, XFF:null, DA:::1/32, IDX:, MET:GET, PTH:/_field_caps, CNT:<N/A>, HDR:Accept=/, Authorization=, Host=localhost:9200, User-Agent=curl/7.68.0, content-length=0, HIS:[PROBE-> RULES:[auth_key->false] RESOLVED:[indices=]], } \u001B[0m", “cluster.uuid”: “-wqFgRwWSW2y52F0eoJT-Q”, “node.id”: “9EhO7lBlTFKm03jvE31flg” }
{“type”: “server”, “timestamp”: “2022-05-28T15:58:48,589Z”, “level”: “DEBUG”, “component”: “t.b.r.a.b.r.AuthKeyRule”, “cluster.name”: “quickstart”, “node.name”: “quickstart-es-default-0”, “message”: “Attempting Login as: admin rc: 889922824-2024090004#2355”, “cluster.uuid”: “-wqFgRwWSW2y52F0eoJT-Q”, “node.id”: “9EhO7lBlTFKm03jvE31flg” }
{“type”: “server”, “timestamp”: “2022-05-28T15:58:48,589Z”, “level”: “DEBUG”, “component”: “t.b.r.a.b.Block”, “cluster.name”: “quickstart”, “node.name”: “quickstart-es-default-0”, “message”: "\u001B[33m[ELASTIC-INTERNAL] the request matches no rules in this block: { ID:889922824-2024090004#2355, TYP:FieldCapabilitiesRequest, CGR:N/A, USR:admin (attempted), BRS:true, KDX:null, ACT:indices:data/read/field_caps, OA:127.0.0.1/32, XFF:null, DA:::1/32, IDX:, MET:GET, PTH:/_field_caps, CNT:<N/A>, HDR:Accept=/, Authorization=, Host=localhost:9200, User-Agent=curl/7.68.0, content-length=0, HIS:[ELASTIC-INTERNAL-> RULES:[auth_key->false] RESOLVED:[indices=]], } \u001B[0m", “cluster.uuid”: “-wqFgRwWSW2y52F0eoJT-Q”, “node.id”: “9EhO7lBlTFKm03jvE31flg” }
{“type”: “server”, “timestamp”: “2022-05-28T15:58:48,590Z”, “level”: “DEBUG”, “component”: “t.b.r.a.b.r.AuthKeyRule”, “cluster.name”: “quickstart”, “node.name”: “quickstart-es-default-0”, “message”: “Attempting Login as: admin rc: 889922824-2024090004#2355”, “cluster.uuid”: “-wqFgRwWSW2y52F0eoJT-Q”, “node.id”: “9EhO7lBlTFKm03jvE31flg” }
{“type”: “server”, “timestamp”: “2022-05-28T15:58:48,590Z”, “level”: “DEBUG”, “component”: “t.b.r.a.b.Block”, “cluster.name”: “quickstart”, “node.name”: “quickstart-es-default-0”, “message”: "\u001B[36mmatched { name: ‘CONTAINER ADMIN - file’, policy: ALLOW, rules: [auth_key] { found: user=admin;indices= }\u001B[0m”, “cluster.uuid”: “-wqFgRwWSW2y52F0eoJT-Q”, “node.id”: “9EhO7lBlTFKm03jvE31flg” }
{“type”: “server”, “timestamp”: “2022-05-28T15:58:48,590Z”, “level”: “INFO”, “component”: “t.b.r.a.l.AccessControlLoggingDecorator”, “cluster.name”: “quickstart”, “node.name”: “quickstart-es-default-0”, “message”: “\u001B[36mALLOWED by { name: ‘CONTAINER ADMIN - file’, policy: ALLOW, rules: [auth_key] req={ ID:889922824-2024090004#2355, TYP:FieldCapabilitiesRequest, CGR:N/A, USR:admin, BRS:true, KDX:null, ACT:indices:data/read/field_caps, OA:127.0.0.1/32, XFF:null, DA:::1/32, IDX:, MET:GET, PTH:/_field_caps, CNT:<N/A>, HDR:Accept=/, Authorization=Basic YWRtaW46Y29udGFpbmVy, Host=localhost:9200, User-Agent=curl/7.68.0, content-length=0, HIS:[::KIBANA-SRV::-> RULES:[auth_key->false] RESOLVED:[indices=]], [DEFAULT KIBANA USER-> RULES:[auth_key->false] RESOLVED:[indices=]], [PROBE-> RULES:[auth_key->false] RESOLVED:[indices=]], [ELASTIC-INTERNAL-> RULES:[auth_key->false] RESOLVED:[indices=]], [CONTAINER ADMIN - file-> RULES:[auth_key->true] RESOLVED:[user=admin;indices=]], }\u001B[0m”, “cluster.uuid”: “-wqFgRwWSW2y52F0eoJT-Q”, “node.id”: “9EhO7lBlTFKm03jvE31flg” }
{“type”: “server”, “timestamp”: “2022-05-28T15:58:48,590Z”, “level”: “DEBUG”, “component”: “t.b.r.e.h.RegularRequestHandler”, “cluster.name”: “quickstart”, “node.name”: “quickstart-es-default-0”, “message”: “[889922824-2024090004#2355] Request processing time: 3ms”, “cluster.uuid”: “-wqFgRwWSW2y52F0eoJT-Q”, “node.id”: “9EhO7lBlTFKm03jvE31flg” }
yes, we are aware of this error. At the moment we are fixing it. It’s not related to ECK but to cooperation of ROR with xpack SSL
@vthatiparthi yes, as @coutoPL stated, this is an ongoing effort for the ROR ES team. It has high priority at the moment, because it limits ECK and overall xpack compatibility.
Hi is there some progress about ECK ROR integration. It will really help us beceuse we are using elastic helm charts which are not supporting 8.x version so we plan to migrate to ECK but we cannot without ROR support…
Thanks guys if you make it usable it will be great …
@coutoPL can comment on this.
@rjan I labelled your user as Enterprise so your requests will bubble up as high priority for us.
@rjan there is no release of ROR with official support for ECK yet. We’re working on it.
But there is a smart workaround to make ROR work with ECK.
Hi Guys,
I am also interested in using ECK with ROR. We are currently working to move our ELK clusters to kubernetes and this is a major blocking point. I would also like to mention that we already have an Enterprise ROR license.
So, is there any advance in this matter?
Thanks,
Diana
we have just released ROR 1.50.0 with ECK support.
You have to enable xpack security (xpack.security.enabled: true ) and patch Elasticsearch after installing ROR. Moreover, you have to use xpack security SSL for HTTP and transport.
The documentation is not updated yet.