Handling .opendistro_security index in helm installations

Security
1

Hi,

Two queries related to opendistro_security index and REST api -

  1. Referring to opendistro docker images & helm charts, the script install_demo_configuration.sh is used in the docker entrypoint to generate demo certificates and configure elasticsearch.yml accordingly.
    But, can you help me understand when does it actually run securityadmin.sh to initialize the .opendistro_security index for the 1st time?
    I see by default opendistro_security.allow_default_init_securityindex is true.
    As I install the helm chart, the opendistro_security index gets created, but I am unable to find the script where it actually executes securityadmin.sh.

  2. Assuming it does run securityadmin.sh on pod’s entrypoint, then how will the security config changes done via REST api survive helm upgrades?
    Scenario -
    a) Install helm chart with default security configurations.
    b) Use security REST API or kibana UI to add new users, roles etc.
    c) Upgrade the helm chart with addition of new envs etc that results in elasticsearch pods to restart.
    Now, the new pods again run securityadmin.sh on their docker-entrypoint and they will update opendistro_security index with the default security configurations. That way the new roles,users and configurations made in step (b) would be lost and replaced with defaults in the .yml files.
    Is this the expected behaviour and is there a better way to handle this especially in helm environments?

Thanks!

2

What we have done to deal with this is to set opendistro_security.allow_default_init_securityindex to false and manually run the securityadmin.sh script the first time. When the pods restart, the script does not run and any/all of the security work we’ve done via the API is left alone.

One complication of this approach is that changes to any of the security configuration files are not picked up on restarts. That’s been fine (so far) for us but could be a bit confusing to later (e.g. “I know I updated roles.yml and I see that the those changes are there on the Elasticsearch pods…and yet those changes aren’t showing up in Elasticseach”).

I know the securityadmin.sh script does support specifying the individual security configuration file to reload, so I suppose that might be how to handle that. But, depending on which security configuration file has changed, re-loading it will wipe out any related changes made via API calls.

I think our policy will be to only use the security configuration files during initialization and all subsequent changes will be via API. To make that easier, we will also remove the reserved labels on most things in the files to allow us to change it later via API calls if needed.