When a user is deleted from the kibana UI its corresponding index (.kibana_<hash>_<username> does not get deleted in case of multitenancy enabled

I am using kibana with multitenancy enabled (1.9.0 security plugin). I have observed that when a user is deleted from UI its corresponding index (.kibana__username ) does not get deleted. After, If any other user gets created with the same name then newuser is able to see all the saved objects created by the previous user since the username was same and it was able to access the index for that user.
Is this expected behaviour or is there anything else needs to be done after deletion of user. Please suggest.
Thanks in advance

It is expected behaviour. AFAIK the index does only get created if the private tenant is used, so one workaround would be to disable the private tenant. If you want to continue using private tenants then I would delete the index at the same time as I delete the user, (I would also avoid reusing usernames as an extra precaution).

The same should be true for “custom tenants” If you delete a tenant you probably want to delete the tenant indices as well.

Okay, thanks for the information. However, I observed that when I create a tenant with name “custom-tenant” and “customtenant”, the index which gets created for these tenants are .kibana_hash_custometenant only. So how can one distinguish which index is related to which tenant?
Please suggest.

IIRC the hash is different. It uses a “standard” java hashCode() method. Here is a python implementation of the hashCode() GitHub - neuront/pyjhashcode: Python implemented Java hashCode methods . The hash is based on the tenant name.

Yes @oscark the hash would be different, but the issue is If I generate say 10 tenants or users then I will not be knowing which hash is associated with which tenant/user. Is there any other feasible solution to find out about index mapping to tenant/user? Please suggest.

@Pratiksha If you have a use case where user names might be familiar, you can always use the hashCode to generate the same hash which can then be compared to the has in the index name before deletion.