Instructions to set up minimal security for elasticsearch

[gunchleoc]

I followed the guide in https://www.elastic.co/guide/en/elasticsearch/reference/7.17/security-minimal-setup.html and ended up with the following settings in /etc/elasticsearch/elasticsearch.yml:

discovery.type: single-node

xpack.security.enabled: true

xpack.security.authc:
  anonymous:
    username: anonymous_user
    roles: superuser
    authz_exception: true

Should this go into the docs at https://docs.joinmastodon.org/admin/optional/elasticsearch/ ?

[Wild1145]

I'd probably suggest we should find a good guide (ideally in elastic's own doc's) and reference to that. There are a lot of reasons the provided config here would be good, but it also wouldn't work if you needed High Availability Elastic, and a lot of this is now set by default in 8.x where they focused on out of the box security enhancements.

[deefdragon]

there were some updates to the elas3docs, but the current docs still recomend granting privileges to all indices. it would be nice to have some index patterns to use instead of just blindly granting to everything.

[mjankowski]

A subsequent PR did add information like this to the guide -- https://github.com/mastodon/documentation/pull/1279 -- taking the approach of linking to relevant docs on ES website.

I'm going to close this on the assumption that's sufficient here ... please reopen if there's something more we can add to those pages?

[deefdragon]

@mjankowski as I mentioned in my comment, I would really like if we could get an index pattern to actually apply to the role. As is, just giving ["read", "monitor", "write", "manage"] to every index is about as close to giving admin access to the entire cluster as one can get without actually doing so. If someone somehow got the credentials, it would allow them full access to everything in the cluster, which is not ideal.

[Wild1145]

@mjankowski as I mentioned in my comment, I would really like if we could get an index pattern to actually apply to the role. As is, just giving ["read", "monitor", "write", "manage"] to every index is about as close to giving admin access to the entire cluster as one can get without actually doing so. If someone somehow got the credentials, it would allow them full access to everything in the cluster, which is not ideal.

They would have access to do what they want to the indices, I would suggest that most people running this are going to have a dedicated ES Instance for their Mastodon servers and aren't going to be "Sharing it", though with that said it is an easy improvement to make. The complexity comes that the indices Mastodon creates and manages aren't prefixed with anything (Which would probably be something to add in an ideal world).

I'd also point out that nothing indexed should by it's nature be sensitive or need any sort of additional safe guards, and in the worst case if someone did manage to get those credentials and even say delete the indices, the data can be re-built from the Mastodon database anyway.

If all of the indices were prefixed I'd agree that it's worth making the change but I do think in this case it would be potentially poor advise to suggest someone be so restrictive as it is likely to break things longer term and frankly the advise should be to run a dedicated ES node / cluster for their mastodon workload not "Sharing" hosting with other apps / services.

EDIT - I've raised an issue here - https://github.com/mastodon/mastodon/issues/36832 to suggest the indexes get renamed as it would be good practice anyway to do so.

[mjankowski]

RE: this comment - https://github.com/mastodon/mastodon/issues/36832#issuecomment-3532102460 - which mentions the already existing ES_PREFIX env var method to use a prefix ...

• Does that help solve the security issues here?
• Would that be a useful addition to the ES docs section (describe how to use the combination of the prefix env var and the narrowed permissions here)?

[Wild1145]

Using a prefix (And recommending that people do that) should solve the security concerns raised and allow the RBAC to be applied specifically to the indices Mastodon uses, the cluster monitor role is fine and isn't going to be a problem the bigger concern (For me) would be the fact it can effectively administer all of the indexes including system managed ones.

I would suggest an update to the docs to recommend a prefix by default and then that same prefix being included in the role permissions in ES would solve the security concerns raised here without impacting functionality (And by the sounds of it is is just a docs change rather than any functional changes).

I haven't tried using the ES_PREFIX myself so there might be more to it than that but assuming all the indexes that are created by chewy for mastodon do use that prefix it should be sufficient to use the updated policy example in the linked ticket.

[mjankowski]

Took a first pass at that - https://github.com/mastodon/documentation/pull/1816 (stopped short of changing default rec, but hopefully captures the idea), feedback there appreciated.