Versions (relevant - OpenSearch/Dashboard/Server OS/Browser): 3.6
Describe the issue:
Either a externally authenticated user or local user cannot see the index pattern in Discover or dashboard with the following roles.
In order for the user to see the data, we have to map the user to the built in kibana_user role. This role gives the user the ability to update or delete internal kibana, opensearch dashboards indices.
Configuration:
PUT /_plugins/_security/api/roles/jeev_custom_role
{
"cluster_permissions": [
"cluster_composite_ops_ro",
"cluster_monitor"
],
"index_permissions": [
{
"index_patterns": [
"logs-apigee-*"
],
"allowed_actions": [
"read",
"indices:admin/mappings/get",
"indices:data/read/field_caps*",
"indices:monitor/stats"
]
},
{
"index_patterns": [
".kibana",
".kibana_1",
".kibana-6",
".kibana_*",
".opensearch_dashboards",
".opensearch_dashboards-6",
".opensearch_dashboards_*",
".tasks",
"*:.tasks"
],
"allowed_actions": [
"read"
]
}
],
"tenant_permissions": [
{
"tenant_patterns": ["jeev"],
"allowed_actions": ["kibana_all_write"]
}
]
}
Relevant Logs or Screenshots:
The index pattern drop down is empty when the user is not mapped to the kibana_user built role.
Thanks
Murali
Do I need to map every user & domain group to the kibana_user built in role ? for the members to access the data ?
@muraliv
kibana_user role - Lets a user sign in and use OpenSearch Dashboards. Grants permissions for cluster read and search, index monitoring, and writing to OpenSearch Dashboards indexes. Combine with read permissions for your data.
Therefore writing to OSD internal indices is indeed included, as this is generally needed when using OSD. However, you do not have to map kibana_user. Can you outline exactly what permissions you want the user to have, For example, should they be able to create/delete index patterns or just view? Any other permissions that they would need?
Hi Anthony,
Thanks a ton for your response. The user should have the following in his tenant space.
View or Select index pattern from the Discover app.
Manage Visualization or Dashboard
Manage Alerts
Thanks
Murali
@muraliv See below example of a role you should be able to use to achieve what you are looking for:
(Note the use of specific .kibana_3258156_jeev_*, if .kibana_* is used, this will give user access to view docs in other tenant indices, such as Global, Admin etc)
{
"jeev_role": {
"cluster_permissions": [
"cluster_composite_ops",
"cluster_monitor",
"cluster:admin/opendistro/alerting/*"
],
"index_permissions": [
{
"index_patterns": [
".kibana",
".kibana-6",
".kibana_3258156_jeev_*" # specific tenant index pattern
],
"fls": [],
"masked_fields": [],
"allowed_actions": [
"read"
]
},
{
"index_patterns": [
"logs-apigee-*"
],
"fls": [],
"masked_fields": [],
"allowed_actions": [
"read",
"indices:admin/mappings/get",
"indices_monitor",
"indices:admin/aliases/get"
]
}
],
"tenant_permissions": [
{
"tenant_patterns": [
"jeev"
],
"allowed_actions": [
"kibana_all_write"
]
}
],
"static": false
}
}
Please confirm if this works for your use case
Hi Anthony,
Thanks again. I have this custom role in this cluster and have a user mapped to this role. When I login as that user, and switch to the tenant, I do not see anything. I also do not see a tenant specific index created.
{
"jeev_custom_role": {
"reserved": false,
"hidden": false,
"cluster_permissions": [
"cluster_composite_ops_ro",
"cluster_monitor"
],
"index_permissions": [
{
"index_patterns": [
"logs-apigee-*"
],
"dls": "",
"fls": [],
"masked_fields": [],
"allowed_actions": [
"read",
"indices:admin/mappings/get",
"indices:data/read/field_caps*",
"indices:monitor/stats",
"indices:monitor/settings/get"
]
},
{
"index_patterns": [
".kibana",
".kibana-6",
".kibana_*",
".opensearch_dashboards",
".opensearch_dashboards-6",
".opensearch_dashboards_*"
],
"dls": "",
"fls": [],
"masked_fields": [],
"allowed_actions": [
"index",
"read",
"indices:monitor/settings/get"
]
}
],
"tenant_permissions": [
{
"tenant_patterns": [
"jeev"
],
"allowed_actions": [
"kibana_all_write"
]
}
],
"static": false
}
}
Thanks
Murali
Hi Anthony,
When I tried to create a role as it is using what u asked me to try, it does not like the “static” key. I removed “static” and I was able to create the role. I mapped the user to this role and switched to that jeev tenant. It did not create the tenant specific index.
Thanks
Murali
@muraliv I noticed you are using cluster_composite_ops_ro, but in my suggestion I’m using cluster_composite_ops. Can you update this and confirm the behaviour please?
Hi Anthony,
Same behavior, it does not create a tenant specific kibana index. Here is the role definition.
{
"jeev_custom_role": {
"reserved": false,
"hidden": false,
"cluster_permissions": [
"cluster_monitor",
"cluster_composite_ops"
],
"index_permissions": [
{
"index_patterns": [
"logs-apigee-*"
],
"dls": "",
"fls": [],
"masked_fields": [],
"allowed_actions": [
"read",
"indices:admin/mappings/get",
"indices:data/read/field_caps*",
"indices:monitor/stats",
"indices:monitor/settings/get"
]
},
{
"index_patterns": [
".kibana",
".kibana-6",
".kibana_*",
".opensearch_dashboards",
".opensearch_dashboards-6",
".opensearch_dashboards_*"
],
"dls": "",
"fls": [],
"masked_fields": [],
"allowed_actions": [
"index",
"read",
"indices:monitor/settings/get"
]
}
],
"tenant_permissions": [
{
"tenant_patterns": [
"jeev"
],
"allowed_actions": [
"kibana_all_write"
]
}
],
"static": false
}
}
This is what we have in the dashboards yml file.
# OpenSearch Security plugin settings for Dashboards
opensearch_security.multitenancy.enabled: true
opensearch_security.multitenancy.tenants.preferred: ["Private", "Global"]
opensearch_security.readonly_mode.roles: ["kibana_read_only"]
I am with all_access and if I switch to another tenant space, it does not create the tenant specific index either.
@muraliv can you share your opensearch_dashboards.yml file, redact any sensitive details please,
Hi Anthony,
Here is my dashboards yml file.
# OpenSearch Dashboards configuration
# Documentation: https://opensearch.org/docs/latest/install-and-configure/install-dashboards/
# Specifies the address to which the OpenSearch Dashboards server will bind.
server.host: 0.0.0.0
# The OpenSearch Dashboards server's name. Used for display purposes.
server.name: "myhost.domain.com"
# Enables SSL and paths to the PEM-format SSL certificate and SSL key files.
server.ssl.enabled: true
server.ssl.certificate: "/etc/opensearch/certs/cert-chained.pem"
server.ssl.key: "/etc/opensearch/certs/cert-key.pem"
# The URLs of the OpenSearch instances to use for all queries.
opensearch.hosts: ['https://search-opensearch.domain.com:443']
# Authentication credentials for the OpenSearch Dashboards server to connect to OpenSearch.
# Uses the internal admin user. For a dedicated dashboards user, create one via
# the security plugin and reference it here instead.
opensearch.username: "kibanaserver"
# TLS settings for the connection between Dashboards and OpenSearch.
opensearch.ssl.verificationMode: full
opensearch.ssl.certificateAuthorities: ["/etc/opensearch/certs/cert-chained.pem"]
# Logging configuration
logging.dest: /apps/opt/application/opensearch-dashboards/logs/opensearch_dashboards.log
logging.verbose: false
# Specifies the path where Dashboards stores data.
path.data: "/apps/opt/application/opensearch-dashboards"
pid.file: "/run/opensearch-dashboards/opensearch-dashboards.pid"
# OpenSearch Security plugin settings for Dashboards
opensearch_security.multitenancy.enabled: true
opensearch_security.multitenancy.tenants.enable_private: true
opensearch_security.multitenancy.tenants.preferred: ["Private", "Global"]
opensearch_security.readonly_mode.roles: ["readonly_dashboard"]
# Cookie-based session management
opensearch_security.cookie.secure: true
opensearch_security.cookie.password: "dkdkdkd"
# Session TTL
opensearch_security.session.ttl: 21600000
opensearch_security.session.keepalive: True
# enable explorer
explore.enabled: true
I was missing this in my opensearch-dashboards.yml file.
# ---------------------------------------------------------------------------
# Request headers
# ---------------------------------------------------------------------------
opensearch.requestHeadersAllowlist:
- authorization
- securitytenant
Hi Anthony,
Thanks a ton for your help :).