Search Guard 5.3.0-11 released

[Jochen Kressin]

We have released Search Guard 5.3.0-11, compatible with Elasticsearch 5.3.0. 

A new version of the Kibana plugin, compatible with Kibana 5.3.0 is also available:

https://github.com/floragunncom/search-guard-kibana-plugin/releases

We also updated the Search Guard Bundle to v11 and the latest versions of all enterprise modules:

https://github.com/floragunncom/search-guard/wiki/Search-Guard-Bundle

-----------------------------------------------------------------------------------------------------------------------------------

Search Guard (®) is an Elasticsearch plugin that offers encryption, authentication and authorisation. 

It builds on Search Guard SSL and provides pluggable auth/auth modules in addition.

[Jochen Kressin]

NOTE: Breaking change!

Please note that Elasticsearch has changed the way index- and delete-operations are handled:

"Make index and delete operation execute as single bulk item" 

https://github.com/elastic/elasticsearch/pull/22812 

This means that if you upgrade from any version prior to 5.3.0, you need to give users with single index- and delete-permissions also permissions for bulk operations!

-----------------------------------------------------------------------------------------------------------------------------------

Search Guard (®) is an Elasticsearch plugin that offers encryption, authentication and authorisation. 

It builds on Search Guard SSL and provides pluggable auth/auth modules in addition.n.

[Fabien Wernli]

Does that include multi-tenancy?

[Jochen Kressin]

No, this is just a compatible version for ES 5.3.0, it's still based on SG v11. Multi tenancy will be included in the Search Guard v12 release. We are currently implementing feature requests like enabling/disabling the global and private tenant etc.

We hope that we can start shipping MT beginning next week. We will start with ES 5.3.0, and work our way down to 5.0.0. 

On Monday, April 3, 2017 at 3:06:41 PM UTC+2, Fabien Wernli wrote:

Does that include multi-tenancy?

[Fabien Wernli]

that sounds awesome, I'm eager to test - I just have to complete our 1.7.3 to 5.2.0 migration (33% complete)

[Lucas Bremgartner]

We just upgraded to 5.3.1 in I get the following error even if the user has access to every index, every type and every action.

Error:

{"error":{"root_cause":[{"type":"security_exception","reason":"no permissions for indices:data/write/bulk"}],"type":"security_exception","reason":"no permissions for indices:data/write/bulk"},"status":403}

sg_roles:

sg_cust_access:

  cluster:

    - 'cluster:admin/repository/put'

    - 'cluster:admin/repository/delete'

    - 'cluster:admin/repository/verify'

    - 'cluster:admin/snapshot/create'

    - 'cluster:admin/snapshot/status'

    - 'cluster:monitor/*'

    - 'indices:admin/template/*'

  indices:

    '*':

      '*':

        - '*'

What have we missed?

[Lucas Bremgartner]

The error goes away, if I add the permission indices:data/write/bulk* as a cluster permission. This is wired, because the mentioned privilege is listed as indices action privilege in https://www.elastic.co/guide/en/shield/2.1/reference.html#ref-actions-list (which is references in https://github.com/floragunncom/search-guard-docs/blob/c6acf6e35f87e6c6adfbeab3bc7f76e164741f27/configuration.md#defining-permissions. 

[Search Guard]

from which version you did the upgrade to 5.3.1? 

Maybe you hit this:

NOTE: Breaking change!

Please note that Elasticsearch has changed the way index- and delete-operations are handled:

"Make index and delete operation execute as single bulk item" 

https://github.com/elastic/elasticsearch/pull/22812 

This means that if you upgrade from any version prior to 5.3.0, you need to give users with single index- and delete-permissions also permissions for bulk operations!

[Lucas Bremgartner]

We updated from version 5.0.2. I am aware of the Breaking change, that is why I asked my question in reply to this notice.

My question is, why is the permission indices:data/write/bulk* a cluster permission? The user in question has all rights on all indices, so why is it failing?

[Jochen Kressin]

Hi Lucas,

this is actually a design decision on our side. A composite action like bulk write, mget or msearch can affect multiple indices in one request. These are resolved internally by ES to individual sub-requests, one for each index. 

Let's assume you have a bulk write to 2 different indices.  This bulk request actually contains three different requests:

• the bulk request itself
  
• two subrequests for the two affected indices
  

The user needs to have:

• the indices:data/write/bulk* permission in cluster level
• This controls whether the user can submit bulk writes at all
• write permission for the two affected indices
• This controls access to the indices

If the user does have the indices:data/write/bulk* permission but lacks write access to one of the two indices, Search Guard would execute the write operation on the index where the user has permissions, and return a 403 for the other index in the sub response.

You are right in the sense that we could allow composite actions implicitely. However, since we're talking about two different permissions here (the composite permission and the write permission for the indices), technically speaking the user indeed needs two different permissions for the request to succeed. Plus, composite actions could be used by an attacker to perform DOS attacks by issuing huge requests affecting a lot of indices. This is why we decided that you need to give a user these composite permissions explicitly. Composite actions need to be defined on cluster level since they affect multiple indices at once.

In the sample action group definition we ship, the corresponding action groups are

• CLUSTER_COMPOSITE_OPS_RO
• CLUSTER_COMPOSITE_OPS

Hope that makes sense!

Thanks,

Jochen