Hi Simone,
In my limited testing I saw a few actions being blocked:
FORBIDDEN by default req={ ID:1928268510-304095439#105189, TYP:SyncedFlushRequest, CGR:N/A, USR:[user not logged], BRS:true, KDX:null, ACT:indices:admin/synced_flush, OA:10.121.81.104/32, XFF:null, DA:10.121.90.58/32, IDX:<N/A>, MET:POST, PTH:/_flush/synced, CNT:<N/A>, HDR:Accept-Encoding=gzip, Authorization=, Content-Length=0, Content-Type=application/json; charset=utf-8, Host=es9k4e591r7-es-http.es9k4e591r7.svc:9200, User-Agent=Go-http-client/1.1, HIS:[Basic Auth credentials-> RULES:[auth_key_sha256->false], RESOLVED:], [Valid JWT viewer-> RULES:[jwt_auth->false], RESOLVED:], [Valid JWT writer-> RULES:[jwt_auth->false], RESOLVED:], [Liveliness and readiness probes-> RULES:[actions->false], RESOLVED:], [Cluster update settings-> RULES:[actions->false], RESOLVED:], [Get Kibana Mappings-> RULES:[actions->false], RESOLVED:], [Master voting-> RULES:[actions->false], RESOLVED:], [Internal requests-> RULES:[actions->false], RESOLVED:] }
The few actions from the operator that I observed were:
- cluster:monitor/state (this I believe is due to the Readiness Probes of the cluster pods)
- cluster:admin/voting_config/add_exclusions, cluster:admin/voting_config/clear_exclusions
- indices:admin/synced_flush
There might be many more, as the operator may be doing some other actions in other scenarios. Is creating ACL blocks by looking through the logs the correct way forward here?
In further discussions, it seems the operator creates a set of users through which it interacts with the cluster. It creates the user in a file realm using the values from two kubernetes secrets, which it creates automatically as part of the cluster formation.
Is there any possible way to import those users in ROR? Or if you have a cleaner approach in your mind then it would be even more helpful.