Elasticsearch Anonymous Authentication

Anonymous authentication

by Jochen Kressin on August 25, 2019

Anonymous authentication

Search Guard provides users with many valuable features to protect data stored in Elasticsearch. However, one may want to make specific indexes accessible to everyone. This can be done with a dummy user and password but this is sort of a dirty hack that we, the engineers, do not like. Fortunately Search Guard includes the anonymous authentication feature that allows you to request Elasticsearch data with no user credentials and precisely specified granted permissions.

Anonymous authentication can be especially useful when you expose Elasticsearch data to other systems. As an example, this may be Elasticsearch & Apache Hive Integration that makes Elasticsearch data available for Apache Hive SQL queries. This may also be any other system that fetches public data from Elasticsearch but is not able to authenticate.

Initial setup

In this post we show a demo, based on Quickstart Elasticsearch Installation with Search Guard enabled. We load the cluster with the sample Shakespeare dataset available here:

curl -H -k 'Content-Type: application/x-ndjson' \
  -XPOST -u admin:admin \ 'https://localhost:9200/shakespeare/doc/_bulk?pretty' \
  --data-binary @shakespeare_6.0.json

This loads Shakespeare texts into shakespeare index. We can now check index content:

curl -k admin:admin 'https://localhost:9200/shakespeare/_search'

and also test that we cannot access the data when no credentials are provided:

curl -k 'https://localhost:9200/shakespeare/_search'

Anonymous authentication

By default, Search Guard will reject any request to Elasticsearch that does not carry some sort of user credentials, like HTTP Basic Authentication, JWT, Kerberos ticket etc. If anonymous authentication is enabled, Search Guard will instead

  • allow the request
  • assign the request automatically to a predefined sg_anonymous user which has the backend role sg_anonymous_backendrole.

This user can then be mapped to one or more Search Guard roles. In effect, all requests that do not have any user credentials will have the permissions configured in these mapped Search Guard roles.

For example, you can allow read access to a public index without authentication, while access to other indices still requires user credentials. Since the Search Guard Kibana plugin also supports anonymous authentication, you can also create publicly available dashboards and visualisations that do not require a login.

Elasticsearch configuration

Anonymous authentication is disabled by default. We need to enable it in sg_config.yml by setting:

searchguard:
 dynamic:
   ...
   http:
     anonymous_auth_enabled: true

Anonymous requests are executed on behalf of a predefined sg_anonymous user which belongs to a single backend role sg_anonymous_backendrole. In our demo, we create a sg_public role in sg_roles.yml which grants read access to the shakespeare index:

sg_public:
 cluster:
   - CLUSTER_COMPOSITE_OPS_RO
 indices:
   'shakespeare':
     '*':
       - READ

We  then map the sg_anonymous_backendrole role to the sg_public Search Guard role in sg_roles_mapping.yml:

sg_public:
 backendroles:
   - sg_anonymous_backendrole

Do not forget to reload cluster configuration:

./sgadmin.sh -cd ../sgconfig/ -icl -nhnv \
  -cacert ../../../config/root-ca.pem \
  -cert ../../../config/kirk.pem \
  -key ../../../config/kirk-key.pem

Demo

First, we can check what user information we get without providing a username and password:

curl -k 'https://localhost:9200/_searchguard/authinfo?pretty'
{
 "user" : "User [name=sg_anonymous, roles=[sg_anonymous_backendrole], requestedTenant=null]",
 "user_name" : "sg_anonymous",
 ...
 "backend_roles" : [
   "sg_anonymous_backendrole"
 ],
 "custom_attribute_names" : [ ],
 ...
 sg_roles: [
  "sg_public"
]

This assures our setup works as expected:

  • The unauthenticated request is executed on behalf of the sg_anonymous user that has the sg_anonymous_backendrole.
  • The user is mapped to the sg_public Search Guard role.

Then, we can fetch Shakespeare index without specifying any user credentials:

curl -k 'https://localhost:9200/shakespeare/_search'
{
  "took": 28,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 111394,
    "max_score": 1.0,
    "hits": [{
          "_index": "shakespeare",
          "_type": "doc",
          "_id": "0",
          "_score": 1.0,
          "_source": {
            "type": "act",
            "line_id": 1,
            "play_name": "Henry IV",
            "speech_number": "",
            "line_number": "",
            "speaker": "",
            "text_entry": "ACT I"
          }
...

As expected, if we try to query another index, Search Guard will raise a security exception:

curl -k 'https://localhost:9200/logs/_search?pretty'
{
  "error" : {
    "root_cause" : [
      {
        "type" : "security_exception",
        "reason" : "no permissions for [indices:data/read/search] and User [name=sg_anonymous, roles=[sg_anonymous_backendrole], requestedTenant=null]"
      }
    ],
    "type" : "security_exception",
    "reason" : "no permissions for [indices:data/read/search] and User [name=sg_anonymous, roles=[sg_anonymous_backendrole], requestedTenant=null]"
  },
  "status" : 403
}

Anonymous authentication with Kibana

The Search Guard Kibana plugin supports anonymous authentication as well. Enable it in kibana.yml like:

searchguard.auth.anonymous_auth_enabled: true

When enabled:

  • The Kibana plugin will not display the login page for unauthenticated users
  • All unauthenticated requests are forwarded to Search Guard, which assigns the anonymous user and permissions as described above
  • In anonymous mode, instead of displaying a logout button, a login button is rendered
  • The login button will show the Search Guard login page where the user can authenticate to get elevated roles and permissions

Anonymous authentication can also be combined with multi tenancy. For example, you can create read only tenants and assign them to the anonymous role. This makes it possible to create publicly available read-only visualisations and dashboards.

Where to go next:

Image: shutterstock / Stunning Art
Jochen KressinAnonymous authentication

Join the conversation