SOLVED - Tenant setup not working. At all. Permissions issue even with 'unlimited' permissions

Security
1

Versions (relevant - OpenSearch/Dashboard/Server OS/Browser):

2.18

Describe the issue:

We are trying to setup tenancy. Within our examplary setup our test users cannot access any index or visualization, even when ‘unlimited’ rights are given to cluster all indices.

Configuration:

We created a tenant, configured a role and a testuser. The testuser is within EntraID, login through OIDC. The role mappings works, we can see differences when manipulating the role. So, we do not except any issues at this stage. After login with our testuser we can change to the new tenant as expected.

The problem begins when trying to see or configure anything. The visualizations page remains completely empty, in Discover no data can be seen, in Index Patterns no patterns can be viewed or created. Extending the permissions to the maximum possible does not change the situation. Only when adding the global tenant things become possible.

From examples, the official docs, and from some online videos we never found statements regarding the global tenant being necessary for a custom tenant to work. Giving permissions to the global tenant would also defeat our purpose of restricting access to that tenant.

Relevant Logs or Screenshots:

Role setup with the now extended rights:

grafik
grafik1810×666 47.2 KB

Logs found in the nodes logs:

{“type”:“log”,“@timestamp”:“2025-06-10T13:29:46Z”,“tags”:[“error”,“opensearch”,“data”],“pid”:1,“message”:“[security_exception]: no permissions for [indices:data/read/search] and User [name=testuser@example.com, backend_roles=[developers], requestedTenant=null]”}

2

@OpenAndreas Could you share role mapping for developers backend role?

Could you also share the role assigned to that user? I see only cluster and index permissions, did you set tenant permissions too?

3

@pablo

Yes, I set the tenants permissions to read/write for that custom tenant.

image
image1762×228 32.6 KB

The role mapping is as follows:

image
image1485×125 8.44 KB

The security* line is my examplary index, btw. I am using the security-auditslogs index for that.

Sorry for the redaction, the tenant has a customer in its name. Those permissions are not the one I want to have in the end. They are just the maximum I could think of in order to demonstrate that I do not have a permissions problem on the index or cluster level.

Within that tenant I see the role being applied:

image
image593×442 21 KB

4

@OpenAndreas Does your user has any other permissions? Do you allow the user read/write .kibana indices? When you run _cat/indices you’ll notice another .kibana index with the reported username.

5

@pablo I think the * should cover all indices, even the .kibana one, or doesn’t it? Anyways, _cat/indices lists lots of indices including .kibana_2 and .kibana_1

To ensure access to the .kibana indices I added

image
image1760×111 4.45 KB

although I think this is redundant. And it did not resolve the issue.

6

@OpenAndreas Do you have the same behaviour with admin user?
Could you share your opensearch_dashboards.yml file?

1 Like
7

@pablo Right now I have to login to that installation through OIDC and cannot use the builtin admin user. My personal user has admin rights and can work with that tenant but this user has read/write access to the global tenant.

This is my opensearch_dashboards.yml:

data.search.usageTelemetry.enabled: false
i18n.locale: en
logging.verbose: true
opensearch.ssl.verificationMode: none
opensearchDashboards.defaultAppId: home
opensearchDashboards.index: .kibana
opensearch_security.auth.type: openid
opensearch_security.cookie.secure: true
opensearch_security.multitenancy.enabled: true
opensearch_security.openid.base_redirect_url: https://opensearch.*********.com
opensearch_security.openid.client_id: 2dad8139-*******8c95a7bab
opensearch_security.openid.client_secret: ${OPENID_CLIENT_SECRET}
opensearch_security.openid.connect_url: https://login.microsoftonline.com/v2.0/.well-known/openid-configuration
opensearch_security.openid.scope: openid email profile offline_access User.Read
opensearch_security.readonly_mode.roles: ["kibana_read_only"]

server.name: opensearch-dashboards
8

OMG - we got it.

@pablo Thanks for pointing us in the right direction! As soon as I posted the Dashboards YAML I realized what is wrong.

SOLULTION: the following config was missing which is - easy to realize - essential for a working tenant setup:

opensearch.requestHeadersWhitelist: [authorization, securitytenant]
2 Likes