[2019-09-19] Opendistro Kibana 6

问题说明：

ELK 6.7.2 升级后Nativer User可以登陆但是通过公司认证的账户无法登陆的情况。

环境介绍：

1. ELK 6.7.2。

2. 使用Opendistro插件实现认证和授权。

3. 通过VIP访问Kibana，然后在VIP和ES之间有Nginx做LB 和 HA。

配置信息：

1. Opendistro配置

1.1 roles.yml

 赋予角色kibana_role_webexgraph相应的权限，在登陆Kibana的时候使用。（这里我只列出了需要注意的一个index权限：.kibana_task_manager，暂时还没有研究这个index是干啥的，反正是需要的，这个index是升级到6.7.2才需要的权限）

kibana_role_graph:

    cluster:

        - UNLIMITED

    indices:

        '?kibana_task*':

            '*':

             - UNLIMITED

1.2 role_mapping.yml 

将公司认证服务器上定义的用户组映射到opendistro定义的角色kibana_role_graph，用于公司账户访问Kibana

kibana_role_graph:

    readonly: true

    backendroles:

        - "CN=***-kibana-***,OU=*** Groups,DC=***,DC=com"

        - "CN=***-kibana-***,OU=Standard,OU=*** Groups,DC=***,DC=com"

问题表现：

 使用Native User登陆时正常使用，但是使用公司认证服务器中注册的用户就报错。报错见图：

问题排查：

1. 检查与公司认证服务器的连接。 OK

2. 查看Opendistro的映射是否正确。 OK

使用Opendistro的API进行验证 https://localhost:9200/_opendistro/_security/authinfo?pretty

检查返回的Role字段是否有存在你在roles.yml中定义的用于访问Kibana的role，这里是kibana_role_graph，如果有说明认证和授权配置的没问题。

3. 查看日志 NO

    3.1 查看Elasticsearch Audit log（感觉没什么问题）

{"audit_cluster_name":"esaas_esbtsj71","audit_node_name":"esbtsj71esc001.***.com","audit_request_initiating_user":"CN=***,OU=Employees,OU=*** Users,DC=***,DC=com","audit_category":"AUTHENTICATED","audit_request_origin":"REST","audit_node_id":"G9-a2HHsQxGVaW2cQ86GnQ","audit_request_layer":"REST","audit_rest_request_path":"/_opendistro/_security/authinfo","@timestamp":"2019-09-18T01:27:22.766+00:00","audit_request_effective_user_is_admin":false,"audit_format_version":3,"audit_utc_timestamp":"2019-09-18T01:27:22.766+00:00","audit_request_remote_address":"0.0.0.0","audit_node_host_address":"0.0.0.0","audit_rest_request_headers":{"Connection":["keep-alive"],"Host":["esbtsj71esc001.***.com:9200"],"Content-Length":["0"]},"audit_request_effective_user":"CN=***,OU=Employees,OU=*** Users,DC=***,DC=com","audit_node_host_name":"esbtsj71esc001.***.com"}

    3.2 查看Kibana Log（没有问题）

    3.3 查看Nginx Log：

    access_log: 没有问题

    error_log：发现问题

2019/09/18 07:00:31 [error] 11301#0: *80 upstream sent too big header while reading response header from upstream, client: 0.0.0.0, server: _, request: "POST /graph/api/v1/auth/login HTTP/1.1", upstream: "https://10.241.89.141:5601/api/v1/auth/login", host: "esbtsj71esc002.***.com", referrer: "https://esbtsj71esc002.***.com/graph/login?nextUrl=%2Fapi%2Fstatus%2F"

解决方案：

一顿百度google，找到原因，nginx作为client转发时使用的，如果header过大，超出了默认的1k，就会引发上述的upstream sent too big header。这样的话在Nginx中放开这个1K的限制就行了。

location /graph/ {

proxy_pass https://kibana_graph/;

proxy_buffer_size 128k;

proxy_buffers 4 256k;

proxy_busy_buffers_size 256k;

}

总结：

一个Nginx的坑让我踩了大半天，还是说需要对错误日志进行详细的分析，这样才能快速解决问题。