Change default index pattern with role // Discover feature

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

Describe the issue:
For clearance it’s not an issue of having access to indices, it’s index pattern feature in discover.
This guy:


I have a hefty amount of index patterns in my setup and now I want to separate access to these indices between teams, yet I can’t figure out a way to make it user friendly.
For example:
I have default index pattern “all” which gives an error and “index*” which shows data as expected from given rule
Can I make it so for certain group index pattern “index*” will be default and for other groups for example “index2*” “index3*” etc. ?
I figured tenants should have some practical use but i can’t find any infromaton on this issue.

@Saidose You need to create separate Tenants where you create desired index patterns. Then assign access to the Tenants with the role.

@pablo Thanks for you answer and time!
Can you perhaps give a more detailed description? I have to create index pattern while being logged into desired tenant? How do I do that so it doesn’t have access to all other index patterns?
However in tenant I’m logged in, I can see index patterns from global tenant even though I’m logged in “example_tenant”

@Saidose You shouldn’t.
So, when you select each tenant you’ll always see the index pattern from Global tenant?

When you run the below command in Dev Tool, do you get more than one .kibana index?

Could you share your opensearch_dashboards.yml and config.yml files?

@pablo Yes, I’ll always see patterns from Global

What command?

This is my setup for dashboards security plugin in config.yml:

server.port: 5601
server.host: 127.0.0.1
opensearch.requestHeadersWhitelist: [authorization, securitytenant]
opensearch_security.multitenancy.enabled: true
opensearch_security.multitenancy.tenants.preferred: [Private, Global]
opensearch_security.readonly_mode.roles: [kibana_read_only]

@Saidose I forgot to add the command.

GET _cat/indices 

The output you’ve posted is from openseach_dashboards.yml. Could you also share config.yml? It is located in the OpenSearch node.

@Saidose Take a look at the documentation.

Multitenancy must be enabled in OpenSearch (config.yml) and OpenSeach Dashboards (opensearch_dashboards.yml).

I’ve reproduced your scenario with multitenancy disabled in config.yml.

@pablo yeah sorry, mistook config.yml for dashboards.yml

The output for the command gives one index:
green open .opensearch_dashboards_1 1 44 6 296.7kb 148.3kb

As for config.yml

_meta:
  type: "config"
  config_version: 2

config:
  dynamic:    
    authc:
      basic_internal_auth_domain:
        http_enabled: true
        transport_enabled: true
        order: 0
        http_authenticator:
          type: basic
          challenge: false
        authentication_backend:
          type: internal


      ldap:
        http_enabled: true
        transport_enabled: false
        order: 1
        http_authenticator:
          type: basic
          challenge: true
        authentication_backend:
          type: ldap
          config:
            enable_ssl: true
            enable_start_tls: false
            enable_ssl_client_auth: false
            verify_hostnames: false
            pemtrustedcas_filepath: *example*
            hosts:
              - *example*
            bind_dn: *example*
            password: *example*
            users:
              primary-userbase:
                 base: *example*
                 search: *example*
              secondary-userbase:
                 base: *example*
                 search: *example*
            username_attribute: *example*
            connect_timeout: 5000
            response_timeout: 0
    authz:
      ldap:
        http_enabled: true
        transport_enabled: true
        authorization_backend:
          type: ldap
          config:
            enable_ssl: true
            enable_start_tls: false
            enable_ssl_client_auth: false
            verify_hostnames: false
            pemtrustedcas_filepath: *example*
            hosts:
              - *example*
            bind_dn: *example*
            password: *example*
            users:
              primary-userbase:
                 base: *example*
                 search: *example*
              secondary-userbase:
                 base: *example*
                 search: *example*
            username_attribute: *example*
            rolebase: *example*
            rolesearch: *example*
            userroleattribute: null
            userrolename: none
            rolename: *example*
            resolve_nested_roles: true

Are you talking about this security config.yaml? I modified it not to include sensitive data

I see, I’ll try to include it in config.yaml in test environment and get back to you with results, thank you very much. It seems I’ve missed a crucial detail whilst being in a rush!