How do I switch off RBAC in Elasticsearch?

Elastic Stack Elasticsearch
1

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.

2

Hi there,

What actually triggers the behavior you are seeing is

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 satisfies your use case ?

3

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 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".

4

Can you share what that error / stacktrace is ?

What version are you on?

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.

5

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. :frowning:

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?

6

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.

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.

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

I don't foresee any

7

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