问题说明：
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的坑让我踩了大半天，还是说需要对错误日志进行详细的分析，这样才能快速解决问题。
网友评论