Currently the elasticsearch clusters can be read or written by more places than strictly need to, as elasticsearch didn't build in any forms of access control. OpenSearch comes with access control enabled by default, this can be disabled to retain the old behaviour.
We have a couple use cases for access control:
* cloudelastic is a read-only service, currently enforced by an http proxy. This could likely be solved by opensearch anonymous authentication. That http proxy also has no other use now, as opensearch does tls termination directly and that was it's prior primary use case.
* We could have a single account. We could have separate accounts for reading and writing. SUP could have a separate account. Cirrus will need connections configured for both purposes, but is likely flexible enough to do that fully through configuration.
* Limiting write access provides stronger guarantees about where writes came from
* The clusters contain private data in the form of both private wikis and deleted title archives. It would be reasonable and prudent to limit read access from our infra to use cases that require it.
A couple questions to answer regarding our migration:
* Do we want to enable Access Control, or continue with the status quo? They can always be enabled at a later date.
* If we enable Access Controls, how should we apply them?
* If we enable Access Controls, how do we manage the accounts? Puppet may need some abstraction added.
* This is mostly an operational question, Cirrus needs only to be provided the appropriate credentials in the connections named to be used for various operations.