[Security] Permissions via Aliases

[stefnestor]

Problem Description

👋🏼 howdy, team & @tvernum!

I see this doc

Aliases containing filters are not a secure way to restrict access to individual documents, due to the limitations described in Index and field names can be leaked when using aliases. The Elastic Stack security features provide a secure way to restrict access to documents through the document-level security feature.

which appears to suggest Role indices permissions should not be granted via aliases. (I'm not fully sure what filtered aliases mean & that may be a gotcha on my side. If we can, let's ignore that sub-point for a moment.)

In v8.6, @tsullivan moved Kibana CSV Reports over to PIT Searches via kibana#144201 which made it reliant on this elasticsearch#75810 PIT Security discussion.

The noticed effect (which I'll cross-link backwards after filing) appears to be any Role indices permissions granted only via Aliases, e.g. Searchable Snapshots partial-MY_INDEX-00001 with alias MY_INDEX, do export via CSV. The fix is for users to update their Role permissions from MY_INDEX to *MY_INDEX* or such.

What I would like to submit as "bug" after confirming I'm on the right page is this doc which appears to claim aliases are valid use:

The following describes the structure of an indices permissions entry:

{
  "names": [ ... ], (1)
  "privileges": [ ... ], 
  "field_security" : { ... }, 
  "query": "..." 
  "allow_restricted_indices": false 
}

(1) A list of data streams, indices, and aliases to which the permissions in this entry apply. Supports wildcards (*).

I'd think to remove aliases and also leave a link to the earlier doc to avoid them when defining this logic.

Steps to Reproduce

• Elasticsearch Version: 8.7.0
• Installed Plugins: defaults
• Java Version: UNK, Elastic Cloud
• OS Version: UNK, Elastic Cloud

(I have backwards cross-link to private discussion.)

[elasticsearchmachine]

Pinging @elastic/es-docs (Team:Docs)

[elasticsearchmachine]

Pinging @elastic/es-security (Team:Security)

[bytebilly]

@stefnestor I'm not sure that the current documentation is incorrect.

Users can actually specify aliases when defining their roles.
There are scenarios where this may not be enough, specifically when using PITs. These additional requirements are already documented in the PIT docs.

The fact that the CSV export in Kibana uses PITs, and that PITs also require read access to the underlying concrete index when opened on an alias looks like an implementation detail that can be added to the CSV export docs.

What do you think?

[mwtyang]

cc @tsullivan @petrklapka @sixstringcode @osmanis

[tvernum]

Aliases containing filters are not a secure way to restrict access to individual documents

which appears to suggest Role indices permissions should not be granted via aliases.

Putting aside the general question as to whether indices permissions should be granted via aliases, that's not what the limitations doc is trying to say.

It specifically means that applying a filter when creating an alias will not provide the security protections that people might expect.

It is the case that sometimes people will assign permissions via an alias because they think that a filter on the alias will be effective at limiting a user's access to individual documents. In that case they are wrong.

But if an admin were to create aliases for prod-logs, dev-logs, without any filters (using only the names of the indices to distinguish prod from dev) and assign permissions to those aliases, then it would work as documented.

[bytebilly]

I just created elastic/kibana#170524 to clarify the additional security requirements when using CSV reports with index aliases, I feel it is the best place to mention that since the page already describes security for that feature.