# How do I switch off RBAC in Elasticsearch?

**URL:** https://discuss.elastic.co/t/how-do-i-switch-off-rbac-in-elasticsearch/210530
**Category:** Elasticsearch
**Tags:** elastic-stack-security
**Created:** [December 4, 2019, 12:15pm UTC](https://discuss.elastic.co/t/how-do-i-switch-off-rbac-in-elasticsearch/210530 "2019-12-04T12:15:13Z")
**Posts on this page:** 7
**Page:** 1

<div class="post-metadata">

### Author: ![Graham\_Leggett](https://avatars.discourse-cdn.com/v4/letter/g/e56c9b/32.png) [@Graham\_Leggett](https://discuss.elastic.co/u/Graham_Leggett)
#### Post date: [December 4, 2019, 12:15pm UTC](https://discuss.elastic.co/t/how-do-i-switch-off-rbac-in-elasticsearch/210530/1 "2019-12-04T12:15:13Z")

</div>

When switching on transport TLS as below, the configuration has the side effect of switching on role based access control on the http frontend, which locks me out of my cluster with a request for a basic authentication password:

xpack.security.transport.ssl.enabled: true  
xpack.security.transport.ssl.verification\_mode: certificate  
xpack.security.transport.ssl.key: machine-server.key  
xpack.security.transport.ssl.certificate: machine-server+issuer.crt  
xpack.security.transport.ssl.certificate\_authorities: machine-issuer+root.crt

How do I completely switch off role based access control?

I want TLS on the transports, and TLS only, no changes to anything else.

The unintended side effects of enabling parts of xpack don't appear to be documented anywhere that I have yet found.

---

<div class="post-metadata">

### Author: ![ikakavas](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ikakavas/32/34430_2.png) [@ikakavas](https://discuss.elastic.co/u/ikakavas)
#### Post date: [December 4, 2019, 2:27pm UTC](https://discuss.elastic.co/t/how-do-i-switch-off-rbac-in-elasticsearch/210530/2 "2019-12-04T14:27:47Z")

</div>

Hi there,

What actually triggers the behavior you are seeing is

```auto
xpack.security.enabled: true

```

which is missing from the above configuration and it is what enables authentication for the REST API. Have you looked into whether [anonymous access](https://www.elastic.co/guide/en/elasticsearch/reference/7.5/anonymous-access.html) satisfies your use case ?

---

<div class="post-metadata">

### Author: ![Graham\_Leggett](https://avatars.discourse-cdn.com/v4/letter/g/e56c9b/32.png) [@Graham\_Leggett](https://discuss.elastic.co/u/Graham_Leggett)
#### Post date: [December 4, 2019, 2:56pm UTC](https://discuss.elastic.co/t/how-do-i-switch-off-rbac-in-elasticsearch/210530/3 "2019-12-04T14:56:58Z")

</div>

We don't use "xpack.security.enabled: true" because doing so triggers a license error.

We use "xpack.security.transport.ssl.enabled: true" instead, but it seems that this triggers unintended consequences inside elasticsearch, and we have no idea what has now broken as a result.

Unfortunately the docs at [https://www.elastic.co/guide/en/elasticsearch/reference/7.5/anonymous-access.html](https://www.elastic.co/guide/en/elasticsearch/reference/7.5/anonymous-access.html) don't fully explain how to configure anonymous access in such a way that all RBAC is off. The docs refer to "role1" and "role2", implying that you have to explicitly specify every role in the server. "Every role" isn't documented in any place I can see, and the next time we do an elasticsearch upgrade we could see new roles appear that have to be explicitly suppressed lest the server suddenly breaks again.

A further issue is resources. If RBAC is initialised, how much CPU and RAM does it take up? We don't want to allocate additional resources to a thing that remains unused.

What I'm looking for is the equivalent of "xpack.rbac.enabled: false".

---

<div class="post-metadata">

### Author: ![ikakavas](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ikakavas/32/34430_2.png) [@ikakavas](https://discuss.elastic.co/u/ikakavas)
#### Post date: [December 4, 2019, 3:28pm UTC](https://discuss.elastic.co/t/how-do-i-switch-off-rbac-in-elasticsearch/210530/4 "2019-12-04T15:28:09Z")

</div>

> [@Graham\_Leggett](#):
>
> We don't use "xpack.security.enabled: true" because doing so triggers a license error.

Can you share what that error / stacktrace is ?

> [@Graham\_Leggett](#):
>
> We use "xpack.security.transport.ssl.enabled: true" instead, but it seems that this triggers unintended consequences inside elasticsearch, and we have no idea what has now broken as a result.

What version are you on?

> [@Graham\_Leggett](#):
>
> Unfortunately the docs at [Enabling anonymous access | Elasticsearch Guide [7.5] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/7.5/anonymous-access.html) don't fully explain how to configure anonymous access in such a way that all RBAC is off.

You basically want all your users to do anything so you could add `superuser` as the role anonymous users get and all your users are superusers.

---

<div class="post-metadata">

### Author: ![Graham\_Leggett](https://avatars.discourse-cdn.com/v4/letter/g/e56c9b/32.png) [@Graham\_Leggett](https://discuss.elastic.co/u/Graham_Leggett)
#### Post date: [December 4, 2019, 7:48pm UTC](https://discuss.elastic.co/t/how-do-i-switch-off-rbac-in-elasticsearch/210530/5 "2019-12-04T19:48:16Z")

</div>

Annoyingly I didn't cut and paste the exception into the bug report. The exception went away when I removed the "xpack.security.enabled: true" and won't come back. ☹

I am using v6.8.5.

> You basically want all your users to do anything so you could add `superuser` as the role anonymous users get and all your users are superusers.

Is there a documented way to do this?

So far we have this, will it work:

```
cluster.name: x-jm-unstable-black
network.host: x-jm-unstable-black-els01.example.com
transport.bind_host: _site_
http.host: _local_
path.logs: /var/log/elasticsearch
path.data: /var/lib/elasticsearch
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.key: machine-server.key
xpack.security.transport.ssl.certificate: machine-server+issuer.crt
xpack.security.transport.ssl.certificate_authorities: machine-issuer+root.crt
xpack.security.authc:
  anonymous:
    roles: superuser
    authz_exception: true

```

Can you confirm what other side effects we can expect from turning xpack on?

---

<div class="post-metadata">

### Author: ![ikakavas](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ikakavas/32/34430_2.png) [@ikakavas](https://discuss.elastic.co/u/ikakavas)
#### Post date: [December 5, 2019, 8:56am UTC](https://discuss.elastic.co/t/how-do-i-switch-off-rbac-in-elasticsearch/210530/6 "2019-12-05T08:56:22Z")

</div>

> [@Graham\_Leggett](#):
>
> Annoyingly I didn't cut and paste the exception into the bug report. The exception went away when I removed the "xpack.security.enabled: true" and won't come back

Maybe this was due to something else ? Or a misconfiguration that has since been resolved ? It will be hard to look into it if this is not reproducible.

> [@Graham\_Leggett](#):
>
> Is there a documented way to do this?

If by "this" you mean a documented way to satisfy your use case, I don't believe we cover this somewhere explicitly - and we can change that - but the way is to use anonymous access and give superuser role to all users.

> [@Graham\_Leggett](#):
>
> So far we have this, will it work:

Yes. You don't even need the `authz_exception: true` part as this is the default value and there will never be some action that superuser can't do so there will never be an authorization exception eitherway

> [@Graham\_Leggett](#):
>
> Can you confirm what other side effects we can expect from turning xpack on?

I don't foresee any

---

<div class="post-metadata">

### Author: ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)
#### Post date: [January 2, 2020, 9:02am UTC](https://discuss.elastic.co/t/how-do-i-switch-off-rbac-in-elasticsearch/210530/7 "2020-01-02T09:02:14Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
