non-super user can't create cross cluster index pattern about stack-docs HOT 6 OPEN

Original comment by @LeeDr:

oh, hold on, my remote data cluster has the kibana_user role, but not the makelogs_reader role. Let me create that and see if it resolves the issue.

curl -k -POST LINK REDACTED -H 'Content-Type: application/json' -d '{
  "cluster": [],
  "indices": [
    {
      "names": [ "makelogs-*" ],
      "privileges": ["read","view_index_metadata","read_cross_cluster"]
    }
  ]
}'

I also switched the user back to having this makelogs_reader role (which exists on both clusters now, and the kibana_user role which also exists on both clusters).

But it still fails.

from stack-docs.

Original comment by @jaymode:

Can you try clearing the role cache on both clusters?

POST /_xpack/security/role/_all/_clear_cache

from stack-docs.

Original comment by @spalger:

@tvernum we figured out that this was being caused by a 403 that gets sent back from elasticsearch when the index pattern send to the _field_caps api doesn't match any indices. @jaymode thought you could help us understand what's going on here.

from stack-docs.

Original comment by @tvernum:

@LeeDr Can you try granting your role the index permission of:

{
        "names": [ "*:*" ],
        "privileges": [ "read" ],
}

Cross cluster security still isn't quite where we want it, and for now the recommended setup is to grant users access to attempt all cross cluster searches.

Right now in 5.4/5.5, security is being applied twice in all cross cluster scenarios. The originating cluster expands and validates the index names, and then the remote cluster does it again.
But the originating cluster can't do that reliably because it doesn't know which remote indices actually exist, so if you try and lock it down too much you get weird behaviours like this one.

It's due to be fixed by LINK REDACTED which will essentially do what I propose above - it will allow every users to perform cross-cluster-search, and then rely solely on the remote cluster to implement security.

from stack-docs.

Original comment by @LeeDr:

@tvernum Yes, that appears to work pretty good. I created a new role ccs_reader in my local cluster with your recommended;

{
        "names": [ "*:*" ],
        "privileges": [ "read" ],
}

and added that role to my user along with kibana_user and my makelogs_reader role. This eliminates the 403 errors I would otherwise see while typing in each character of the index pattern name (until it matched). And I confirmed it does NOT let me see any data in the remote cluster that isn't granted through a role on that remote cluster.

In my local cluster, that makelogs_reader has;

{
        "names": [ "makelogs-*", "*:makelogs-*" ],
        "privileges": [ "read", "view_index_metadata", "read_cross_cluster" ],
}

In the remote "data" cluster that makelogs_reader role has;

{
        "names": [ "makelogs-*" ],
        "privileges": [ "read", "view_index_metadata", "read_cross_cluster" ],
}

This combination allows the makelogs_reader user to create these index patterns in Kibana;

• makelogs-*
• local:makelogs-*
• data:makelogs-*
• *:makelogs-*

I could just have makelogs-* and data:makelogs-* and in that case the local makelogs_reader role would not need "read_cross_cluster". But I want to be able to search across both the local and remote clusters with one index pattern (and also separately) so I configured my local cluster in cross cluster search as "local" and can use *:makelogs-* to combine results.

I added a docs label. I think we likely need to enhance some docs around this, and/or a blog, or release notes, or something...

from stack-docs.

Original comment by @tvernum:

I think we likely need to enhance some docs around this, and/or a blog, or release notes, or something...

Yes. When we thought we'd have it fixed in 5.5 we took the minimalist approach of just making sure the examples in the docs always used *:*. Since we're about to ship Kibana features for CCS, but haven't got security to 100% we need to document it more clearly.

Because it's really a stack issue - ES & XPack with Kibana & XPack a blog post might be the best avenue to get a clear message out, but it's probably worth putting a note in the CSS security page to explain what the current state looks like and where it's heading too.

from stack-docs.