SearchGuard Version: 6.2.3-22.1
SearchGuard Kibana version: 6.2.3-13
Elasticsearch Version: 6.2.3
openjdk version “1.8.0_171”
OpenJDK Runtime Environment (build 1.8.0_171-b10)
OpenJDK 64-Bit Server VM (build 25.171-b10, mixed mode)
I’m using the kibana multi tenancy plugin and have user access restricted in searchguard to only indexes that have the username prefix. For example, user “johndoe” can only access indexes with a prefix “johndoe-*”. This access seems to work fine except when searching for indexes in kibana to create an index pattern. Even though the user only has access to their own index, they can still see other indexes.
If the user creates an index pattern on an index they have access to, it works just fine but if they create an index pattern to an index they don’t have access to, it gives a permission error once they create the pattern. It also prevents them from deleting or being able to manage any of the index patterns because the “Index Patterns” page fails to load. The error that is show is: [object Object]: [security_exception] no permissions for [indices:data/read/field_caps]
I figured that I could get around this issue by setting the “do_not_fail_on_forbidden” option to true but that doesn’t seem to take affect at all.
I’m trying to either get the “do_not_fail_on_forbidden” option to work. A better option would be if I can only show indexes that the user has access to on the search results when creating an index pattern.
This is what my searchguard config looks like. I used the sgadmin to pull the config from the cluster. Its basically all the default settings except for the “do_not_fail_on_forbidden” option.
···
searchguard:
dynamic:
kibana:
do_not_fail_on_forbidden: true
http:
anonymous_auth_enabled: false
xff:
enabled: false
internalProxies: “192\.168\.0\.10|192\.168\.0\.11”
remoteIpHeader: “x-forwarded-for”
proxiesHeader: “x-forwarded-by”
authc:
kerberos_auth_domain:
http_enabled: false
transport_enabled: false
order: 6
http_authenticator:
type: “kerberos”
challenge: true
config:
krb_debug: false
strip_realm_from_principal: true
authentication_backend:
type: “noop”
basic_internal_auth_domain:
http_enabled: true
transport_enabled: true
order: 4
http_authenticator:
type: “basic”
challenge: true
authentication_backend:
type: “intern”
proxy_auth_domain:
http_enabled: false
transport_enabled: false
order: 3
http_authenticator:
type: “proxy”
challenge: false
config:
user_header: “x-proxy-user”
roles_header: “x-proxy-roles”
authentication_backend:
type: “noop”
jwt_auth_domain:
http_enabled: false
transport_enabled: false
order: 0
http_authenticator:
type: “jwt”
challenge: false
config:
signing_key: “base64 encoded HMAC key or public RSA/ECDSA pem key”
jwt_header: “Authorization”
jwt_url_parameter: null
roles_key: null
subject_key: null
authentication_backend:
type: “noop”
clientcert_auth_domain:
http_enabled: false
transport_enabled: false
order: 2
http_authenticator:
type: “clientcert”
config:
username_attribute: “cn”
challenge: false
authentication_backend:
type: “noop”
ldap:
http_enabled: false
transport_enabled: false
order: 5
http_authenticator:
type: “basic”
challenge: false
authentication_backend:
type: “ldap”
config:
enable_ssl: false
enable_start_tls: false
enable_ssl_client_auth: false
verify_hostnames: true
hosts:
- “localhost:8389”
bind_dn: null
password: null
userbase: “ou=people,dc=example,dc=com”
usersearch: “(sAMAccountName={0})”
username_attribute: null
authz:
roles_from_myldap:
http_enabled: false
transport_enabled: false
authorization_backend:
type: “ldap”
config:
enable_ssl: false
enable_start_tls: false
enable_ssl_client_auth: false
verify_hostnames: true
hosts:
- “localhost:8389”
bind_dn: null
password: null
rolebase: “ou=groups,dc=example,dc=com”
rolesearch: “(member={0})”
userroleattribute: null
userrolename: “disabled”
rolename: “cn”
resolve_nested_roles: true
userbase: “ou=people,dc=example,dc=com”
usersearch: “(uid={0})”
roles_from_another_ldap:
enabled: false
authorization_backend:
type: “ldap”
The permissions for the role associated with the user are as follows.
Cluster Permissons: CLUSTER_MONITOR action group
Index Permissions: ${user_name)-* index with a document type of “*” and a permission of READ action group.
The action groups are the default ones setup when the searchguard index is initialized and have not been modified.
) does something different: If the user issues queries that span multiple indices, like msearch for example, it returns only the data from indices where the user has access to. If it is set to false, the query would fail altogether. Both scenarios are valid, and which one is more suitable depends on the use case. Since Kibana performs a lot of msearches and wildcard searches, we usually recommend to set it to true for this case.