More fine grained privilege than "manage" on indices?

[JohanRask]

We are forced to use a specific user for deployment and we are performing a /_flush/synced during installation. As I understand, I can not have more fine grained control than "manage" which means that this user can also delete indices, is this correct?

Regards /Johan

[Albert_Zaharovits]

Hello @JohanRask

Yes, It is true that granting the manage index privilege will allow the user to delete indices.

That's because we define and name union of privileges that we consider are usable together. This is a maintenance and usability balancing act. There exist fine grained privileges that we don't expose.
In your case, you could add indices:admin/flush instead of manage (which as you pointed out is a superset). The user would only have privileges to call the _flush API.

We generally don't encourage using low level privilege names because changing these is the only way we can "rebalance" them into more relevant unions that we then expose. That is, we will change them when we decide we need to restructure the model without thinking about backwards compatibility (this would be in the release notes though).

As a feedback to us, can you please share the complete set of privileges your deployment user requires?

[JohanRask]

Thanks!

admin/flush will do the trick for now!

We are doing it by the book as specified in the documentation for rolling restarts/upgrades BUT this is an enterprise where the installation is not performed by us and we do not know when it will be performed so everything has to be fully automated.

Currently we have (cluster=monitor+manage) so we can track progress for cluster status and also track relocating+init shards when doing a version upgrade. We disable shard allocation and perform a flush/synced before taking each node down.

Basically, we do not need complete cluster=manage or indices=manage, only those specified above.

Is this enough?

/Johan

[Albert_Zaharovits]

Understood, thanks!