302 redirect loop when following HTML links to Kibana after ES upgrade to 6.6.0, Searchguard 24.1

Tomas_Hellberg · February 6, 2019, 1:33pm

Since I upgraded Elastic and Kibana to 6.6.0 (and searchguard 24.1 / 18), I get in a weird 302 redirect loop when following HTML links to Kibana.

Given an HTML page with the following code

Kibana

and clicking the link “Kibana” results in the browser getting stuck in a 302 redirect loop alternating between

/auth/anonymous?nextUrl=%2Fapp%2Fkibana

and

/app/kibana

Chrome aborts with ERR_TOO_MANY_REDIRECTS.

However if I enter the URL of the link (http://kibana.corp.int/app/kibana#) directly in the address bar (or follow a bookmark), the link works fine.

Could this be related to Searchguard?

jkressin · February 6, 2019, 4:41pm

This looks weird. At the moment I don’t see a direct connection between the behavior and the SG plugin code. IMHO the only difference between the requests is that the request that stems from the link has a referrer field, whereas the direct URL would not. But there is no place in the code where we (means SG) makes use of the referrer field.

You write that you see both:

/auth/anonymous?nextUrl=%2Fapp%2Fkibana

``

and

/app/kibana

``

Do you have anonymous authentication enabled in Kibana?

Is there any difference in the behavior if you use

http://kibana.corp.int

``

instead of

http://kibana.corp.int /app/kibana#

``

Could you post the kibana.yml and elasticsearch.yml?

Thanks!

···

On Wednesday, February 6, 2019 at 2:33:39 PM UTC+1, Tomas Hellberg wrote:

Since I upgraded Elastic and Kibana to 6.6.0 (and searchguard 24.1 / 18), I get in a weird 302 redirect loop when following HTML links to Kibana.

Given an HTML page with the following code

Kibana

and clicking the link “Kibana” results in the browser getting stuck in a 302 redirect loop alternating between

/auth/anonymous?nextUrl=%2Fapp%2Fkibana

and

/app/kibana

Chrome aborts with ERR_TOO_MANY_REDIRECTS.

However if I enter the URL of the link (http://kibana.corp.int/app/kibana#) directly in the address bar (or follow a bookmark), the link works fine.

Could this be related to Searchguard?

Tomas_Hellberg · February 6, 2019, 6:51pm

No difference if I use / or /app/kibana#. We have anonymous access enabled, and I see no difference if I’m logged in or not. Also tried incognito mode, but same behavior.

kibana.yml

Default Kibana configuration from kibana-docker.

server.name: kibana

server.host: “0.0.0.0”

elasticsearch.url: “https://elasticsearch:9200”

elasticsearch.username: “kibanaserver”

elasticsearch.password: “kibanaserver”

elasticsearch.ssl.verificationMode: none

elasticsearch.requestHeadersWhitelist: [“Authorization”, “sgtenant”]

xpack.monitoring.ui.container.elasticsearch.enabled: true

xpack.security.enabled: false

xpack.reporting.queue.timeout: 600000

searchguard.auth.anonymous_auth_enabled: true

searchguard.auth.type: “basicauth”

searchguard.basicauth.forbidden_usernames: [“kibanaserver”, “logstash”]

searchguard.basicauth.login.title: “Welcome to Kibana and Elasticsearch”

searchguard.basicauth.login.subtitle: “This Elasticsearch cluster is managed by the CI team”

kibana.index: KIBANA_INDEX

xpack.spaces.enabled: true

elasticsearch.yml

···

cluster.name: “docker-cluster”

bootstrap.memory_lock: true

action.destructive_requires_name: true

xpack.monitoring.collection.enabled: true

xpack.security.enabled: false

node.master: true

node.name: “node-001”

network.publish_host: “10.33.14.74”

node.name: “node-002”

network.publish_host: “10.33.9.91”

node.name: “node-003”

network.publish_host: “10.33.9.92”

node.name: “node-004”

network.publish_host: “10.33.9.93”

reindex.remote.whitelist: “.int:”

http.port: 9200

transport.tcp.port: 9300

network.host: “0.0.0.0”

Node | Elasticsearch Guide [8.11] | Elastic

discovery.zen.minimum_master_nodes: 3

discovery.zen.hosts_provider: file

path.repo: [“/backup/elasticsearch”]

searchguard.enterprise_modules_enabled: false

######## Start Search Guard Demo Configuration ########

WARNING: revise all the lines below before you go into production

searchguard.ssl.transport.pemcert_filepath: esnode.pem

searchguard.ssl.transport.pemkey_filepath: esnode-key.pem

searchguard.ssl.transport.pemtrustedcas_filepath: root-ca.pem

searchguard.ssl.transport.enforce_hostname_verification: false

searchguard.ssl.http.enabled: true

searchguard.ssl.http.pemcert_filepath: esnode.pem

searchguard.ssl.http.pemkey_filepath: esnode-key.pem

searchguard.ssl.http.pemtrustedcas_filepath: root-ca.pem

searchguard.allow_unsafe_democertificates: true

searchguard.authcz.admin_dn:

CN=kirk,OU=client,O=client,L=test, C=de

searchguard.audit.type: internal_elasticsearch

searchguard.enable_snapshot_restore_privilege: true

searchguard.check_snapshot_restore_write_privileges: true

searchguard.restapi.roles_enabled: [“sg_all_access”]

cluster.routing.allocation.disk.threshold_enabled: false

node.max_local_storage_nodes: 3

######## End Search Guard Demo Configuration ########

On Wednesday, 6 February 2019 17:41:21 UTC+1, Jochen Kressin wrote:

This looks weird. At the moment I don’t see a direct connection between the behavior and the SG plugin code. IMHO the only difference between the requests is that the request that stems from the link has a referrer field, whereas the direct URL would not. But there is no place in the code where we (means SG) makes use of the referrer field.

You write that you see both:

/auth/anonymous?nextUrl=%2Fapp%2Fkibana

``

and

/app/kibana

``

Do you have anonymous authentication enabled in Kibana?

https://docs.search-guard.com/latest/kibana-authentication-anonymous

Is there any difference in the behavior if you use

http://kibana.corp.int

``

instead of

http://kibana.corp.int /app/kibana#

``

Could you post the kibana.yml and elasticsearch.yml?

Thanks!

On Wednesday, February 6, 2019 at 2:33:39 PM UTC+1, Tomas Hellberg wrote:

Since I upgraded Elastic and Kibana to 6.6.0 (and searchguard 24.1 / 18), I get in a weird 302 redirect loop when following HTML links to Kibana.

Given an HTML page with the following code

Kibana

and clicking the link “Kibana” results in the browser getting stuck in a 302 redirect loop alternating between

/auth/anonymous?nextUrl=%2Fapp%2Fkibana

and

/app/kibana

Chrome aborts with ERR_TOO_MANY_REDIRECTS.

However if I enter the URL of the link (http://kibana.corp.int/app/kibana#) directly in the address bar (or follow a bookmark), the link works fine.

Could this be related to Searchguard?

jkressin · February 6, 2019, 7:12pm

Ok thanks. So far we were not able to reproduce this. Just to make sure, you have anonymous auth also enabled in sg_config.ym right?

https://docs.search-guard.com/latest/anonymous-authentication

···

On Wednesday, February 6, 2019 at 7:51:11 PM UTC+1, Tomas Hellberg wrote:

No difference if I use / or /app/kibana#. We have anonymous access enabled, and I see no difference if I’m logged in or not. Also tried incognito mode, but same behavior.

kibana.yml

Default Kibana configuration from kibana-docker.

server.name: kibana

server.host: “0.0.0.0”

elasticsearch.url: “https://elasticsearch:9200”

elasticsearch.username: “kibanaserver”

elasticsearch.password: “kibanaserver”

elasticsearch.ssl.verificationMode: none

elasticsearch.requestHeadersWhitelist: [“Authorization”, “sgtenant”]

xpack.monitoring.ui.container.elasticsearch.enabled: true

xpack.security.enabled: false

xpack.reporting.queue.timeout: 600000

searchguard.auth.anonymous_auth_enabled: true

searchguard.auth.type: “basicauth”

searchguard.basicauth.forbidden_usernames: [“kibanaserver”, “logstash”]

searchguard.basicauth.login.title: “Welcome to Kibana and Elasticsearch”

searchguard.basicauth.login.subtitle: “This Elasticsearch cluster is managed by the CI team”

kibana.index: KIBANA_INDEX

xpack.spaces.enabled: true

elasticsearch.yml

cluster.name: “docker-cluster”

bootstrap.memory_lock: true

action.destructive_requires_name: true

xpack.monitoring.collection.enabled: true

xpack.security.enabled: false

node.master: true

node.name: “node-001”

network.publish_host: “10.33.14.74”

node.name: “node-002”

network.publish_host: “10.33.9.91”

node.name: “node-003”

network.publish_host: “10.33.9.92”

node.name: “node-004”

network.publish_host: “10.33.9.93”

reindex.remote.whitelist: “.int:”

http.port: 9200

transport.tcp.port: 9300

network.host: “0.0.0.0”

https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html#split-brain

discovery.zen.minimum_master_nodes: 3

discovery.zen.hosts_provider: file

path.repo: [“/backup/elasticsearch”]

searchguard.enterprise_modules_enabled: false

######## Start Search Guard Demo Configuration ########

WARNING: revise all the lines below before you go into production

searchguard.ssl.transport.pemcert_filepath: esnode.pem

searchguard.ssl.transport.pemkey_filepath: esnode-key.pem

searchguard.ssl.transport.pemtrustedcas_filepath: root-ca.pem

searchguard.ssl.transport.enforce_hostname_verification: false

searchguard.ssl.http.enabled: true

searchguard.ssl.http.pemcert_filepath: esnode.pem

searchguard.ssl.http.pemkey_filepath: esnode-key.pem

searchguard.ssl.http.pemtrustedcas_filepath: root-ca.pem

searchguard.allow_unsafe_democertificates: true

searchguard.authcz.admin_dn:

CN=kirk,OU=client,O=client,L=test, C=de

searchguard.audit.type: internal_elasticsearch

searchguard.enable_snapshot_restore_privilege: true

searchguard.check_snapshot_restore_write_privileges: true

searchguard.restapi.roles_enabled: [“sg_all_access”]

cluster.routing.allocation.disk.threshold_enabled: false

node.max_local_storage_nodes: 3

######## End Search Guard Demo Configuration ########

On Wednesday, 6 February 2019 17:41:21 UTC+1, Jochen Kressin wrote:

This looks weird. At the moment I don’t see a direct connection between the behavior and the SG plugin code. IMHO the only difference between the requests is that the request that stems from the link has a referrer field, whereas the direct URL would not. But there is no place in the code where we (means SG) makes use of the referrer field.

You write that you see both:

/auth/anonymous?nextUrl=%2Fapp%2Fkibana

``

and

/app/kibana

``

Do you have anonymous authentication enabled in Kibana?

https://docs.search-guard.com/latest/kibana-authentication-anonymous

Is there any difference in the behavior if you use

http://kibana.corp.int

``

instead of

http://kibana.corp.int /app/kibana#

``

Could you post the kibana.yml and elasticsearch.yml?

Thanks!

On Wednesday, February 6, 2019 at 2:33:39 PM UTC+1, Tomas Hellberg wrote:

Since I upgraded Elastic and Kibana to 6.6.0 (and searchguard 24.1 / 18), I get in a weird 302 redirect loop when following HTML links to Kibana.

Given an HTML page with the following code

Kibana

and clicking the link “Kibana” results in the browser getting stuck in a 302 redirect loop alternating between

/auth/anonymous?nextUrl=%2Fapp%2Fkibana

and

/app/kibana

Chrome aborts with ERR_TOO_MANY_REDIRECTS.

However if I enter the URL of the link (http://kibana.corp.int/app/kibana#) directly in the address bar (or follow a bookmark), the link works fine.

Could this be related to Searchguard?

Tomas_Hellberg · February 6, 2019, 7:16pm

sg_config.yml:
http:

  anonymous_auth_enabled: true

···

On Wednesday, 6 February 2019 20:12:50 UTC+1, Jochen Kressin wrote:

Ok thanks. So far we were not able to reproduce this. Just to make sure, you have anonymous auth also enabled in sg_config.ym right?

https://docs.search-guard.com/latest/anonymous-authentication

On Wednesday, February 6, 2019 at 7:51:11 PM UTC+1, Tomas Hellberg wrote:

No difference if I use / or /app/kibana#. We have anonymous access enabled, and I see no difference if I’m logged in or not. Also tried incognito mode, but same behavior.

kibana.yml

Default Kibana configuration from kibana-docker.

server.name: kibana

server.host: “0.0.0.0”

elasticsearch.url: “https://elasticsearch:9200”

elasticsearch.username: “kibanaserver”

elasticsearch.password: “kibanaserver”

elasticsearch.ssl.verificationMode: none

elasticsearch.requestHeadersWhitelist: [“Authorization”, “sgtenant”]

xpack.monitoring.ui.container.elasticsearch.enabled: true

xpack.security.enabled: false

xpack.reporting.queue.timeout: 600000

searchguard.auth.anonymous_auth_enabled: true

searchguard.auth.type: “basicauth”

searchguard.basicauth.forbidden_usernames: [“kibanaserver”, “logstash”]

searchguard.basicauth.login.title: “Welcome to Kibana and Elasticsearch”

searchguard.basicauth.login.subtitle: “This Elasticsearch cluster is managed by the CI team”

kibana.index: KIBANA_INDEX

xpack.spaces.enabled: true

elasticsearch.yml

cluster.name: “docker-cluster”

bootstrap.memory_lock: true

action.destructive_requires_name: true

xpack.monitoring.collection.enabled: true

xpack.security.enabled: false

node.master: true

node.name: “node-001”

network.publish_host: “10.33.14.74”

node.name: “node-002”

network.publish_host: “10.33.9.91”

node.name: “node-003”

network.publish_host: “10.33.9.92”

node.name: “node-004”

network.publish_host: “10.33.9.93”

reindex.remote.whitelist: “.int:”

http.port: 9200

transport.tcp.port: 9300

network.host: “0.0.0.0”

https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html#split-brain

discovery.zen.minimum_master_nodes: 3

discovery.zen.hosts_provider: file

path.repo: [“/backup/elasticsearch”]

searchguard.enterprise_modules_enabled: false

######## Start Search Guard Demo Configuration ########

WARNING: revise all the lines below before you go into production

searchguard.ssl.transport.pemcert_filepath: esnode.pem

searchguard.ssl.transport.pemkey_filepath: esnode-key.pem

searchguard.ssl.transport.pemtrustedcas_filepath: root-ca.pem

searchguard.ssl.transport.enforce_hostname_verification: false

searchguard.ssl.http.enabled: true

searchguard.ssl.http.pemcert_filepath: esnode.pem

searchguard.ssl.http.pemkey_filepath: esnode-key.pem

searchguard.ssl.http.pemtrustedcas_filepath: root-ca.pem

searchguard.allow_unsafe_democertificates: true

searchguard.authcz.admin_dn:

CN=kirk,OU=client,O=client,L=test, C=de

searchguard.audit.type: internal_elasticsearch

searchguard.enable_snapshot_restore_privilege: true

searchguard.check_snapshot_restore_write_privileges: true

searchguard.restapi.roles_enabled: [“sg_all_access”]

cluster.routing.allocation.disk.threshold_enabled: false

node.max_local_storage_nodes: 3

######## End Search Guard Demo Configuration ########

On Wednesday, 6 February 2019 17:41:21 UTC+1, Jochen Kressin wrote:

This looks weird. At the moment I don’t see a direct connection between the behavior and the SG plugin code. IMHO the only difference between the requests is that the request that stems from the link has a referrer field, whereas the direct URL would not. But there is no place in the code where we (means SG) makes use of the referrer field.

You write that you see both:

/auth/anonymous?nextUrl=%2Fapp%2Fkibana

``

and

/app/kibana

``

Do you have anonymous authentication enabled in Kibana?

https://docs.search-guard.com/latest/kibana-authentication-anonymous

Is there any difference in the behavior if you use

http://kibana.corp.int

``

instead of

http://kibana.corp.int /app/kibana#

``

Could you post the kibana.yml and elasticsearch.yml?

Thanks!

On Wednesday, February 6, 2019 at 2:33:39 PM UTC+1, Tomas Hellberg wrote:

Since I upgraded Elastic and Kibana to 6.6.0 (and searchguard 24.1 / 18), I get in a weird 302 redirect loop when following HTML links to Kibana.

Given an HTML page with the following code

Kibana

and clicking the link “Kibana” results in the browser getting stuck in a 302 redirect loop alternating between

/auth/anonymous?nextUrl=%2Fapp%2Fkibana

and

/app/kibana

Chrome aborts with ERR_TOO_MANY_REDIRECTS.

However if I enter the URL of the link (http://kibana.corp.int/app/kibana#) directly in the address bar (or follow a bookmark), the link works fine.

Could this be related to Searchguard?

Tomas_Hellberg · February 15, 2019, 10:10pm

I’ve done some more testing now and I’ve reproduced this in a local Docker environment.

If I set “anonymous_auth_enabled: false”, I instead end up on the login page every time I click on a HTML link to Kibana:

/login?nextUrl=%2Fapp%2Fkibana#?_g=()

This happens even if I’m already logged in, so there is some kind of authentication problem I guess. Maybe some authentication token that is not passed on correctly?

···

On Wednesday, 6 February 2019 20:12:50 UTC+1, Jochen Kressin wrote:

Ok thanks. So far we were not able to reproduce this. Just to make sure, you have anonymous auth also enabled in sg_config.ym right?

https://docs.search-guard.com/latest/anonymous-authentication

On Wednesday, February 6, 2019 at 7:51:11 PM UTC+1, Tomas Hellberg wrote:

No difference if I use / or /app/kibana#. We have anonymous access enabled, and I see no difference if I’m logged in or not. Also tried incognito mode, but same behavior.

kibana.yml

Default Kibana configuration from kibana-docker.

server.name: kibana

server.host: “0.0.0.0”

elasticsearch.url: “https://elasticsearch:9200”

elasticsearch.username: “kibanaserver”

elasticsearch.password: “kibanaserver”

elasticsearch.ssl.verificationMode: none

elasticsearch.requestHeadersWhitelist: [“Authorization”, “sgtenant”]

xpack.monitoring.ui.container.elasticsearch.enabled: true

xpack.security.enabled: false

xpack.reporting.queue.timeout: 600000

searchguard.auth.anonymous_auth_enabled: true

searchguard.auth.type: “basicauth”

searchguard.basicauth.forbidden_usernames: [“kibanaserver”, “logstash”]

searchguard.basicauth.login.title: “Welcome to Kibana and Elasticsearch”

searchguard.basicauth.login.subtitle: “This Elasticsearch cluster is managed by the CI team”

kibana.index: KIBANA_INDEX

xpack.spaces.enabled: true

elasticsearch.yml

cluster.name: “docker-cluster”

bootstrap.memory_lock: true

action.destructive_requires_name: true

xpack.monitoring.collection.enabled: true

xpack.security.enabled: false

node.master: true

node.name: “node-001”

network.publish_host: “10.33.14.74”

node.name: “node-002”

network.publish_host: “10.33.9.91”

node.name: “node-003”

network.publish_host: “10.33.9.92”

node.name: “node-004”

network.publish_host: “10.33.9.93”

reindex.remote.whitelist: “.int:”

http.port: 9200

transport.tcp.port: 9300

network.host: “0.0.0.0”

https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html#split-brain

discovery.zen.minimum_master_nodes: 3

discovery.zen.hosts_provider: file

path.repo: [“/backup/elasticsearch”]

searchguard.enterprise_modules_enabled: false

######## Start Search Guard Demo Configuration ########

WARNING: revise all the lines below before you go into production

searchguard.ssl.transport.pemcert_filepath: esnode.pem

searchguard.ssl.transport.pemkey_filepath: esnode-key.pem

searchguard.ssl.transport.pemtrustedcas_filepath: root-ca.pem

searchguard.ssl.transport.enforce_hostname_verification: false

searchguard.ssl.http.enabled: true

searchguard.ssl.http.pemcert_filepath: esnode.pem

searchguard.ssl.http.pemkey_filepath: esnode-key.pem

searchguard.ssl.http.pemtrustedcas_filepath: root-ca.pem

searchguard.allow_unsafe_democertificates: true

searchguard.authcz.admin_dn:

CN=kirk,OU=client,O=client,L=test, C=de

searchguard.audit.type: internal_elasticsearch

searchguard.enable_snapshot_restore_privilege: true

searchguard.check_snapshot_restore_write_privileges: true

searchguard.restapi.roles_enabled: [“sg_all_access”]

cluster.routing.allocation.disk.threshold_enabled: false

node.max_local_storage_nodes: 3

######## End Search Guard Demo Configuration ########

On Wednesday, 6 February 2019 17:41:21 UTC+1, Jochen Kressin wrote:

This looks weird. At the moment I don’t see a direct connection between the behavior and the SG plugin code. IMHO the only difference between the requests is that the request that stems from the link has a referrer field, whereas the direct URL would not. But there is no place in the code where we (means SG) makes use of the referrer field.

You write that you see both:

/auth/anonymous?nextUrl=%2Fapp%2Fkibana

``

and

/app/kibana

``

Do you have anonymous authentication enabled in Kibana?

https://docs.search-guard.com/latest/kibana-authentication-anonymous

Is there any difference in the behavior if you use

http://kibana.corp.int

``

instead of

http://kibana.corp.int /app/kibana#

``

Could you post the kibana.yml and elasticsearch.yml?

Thanks!

On Wednesday, February 6, 2019 at 2:33:39 PM UTC+1, Tomas Hellberg wrote:

Since I upgraded Elastic and Kibana to 6.6.0 (and searchguard 24.1 / 18), I get in a weird 302 redirect loop when following HTML links to Kibana.

Given an HTML page with the following code

Kibana

and clicking the link “Kibana” results in the browser getting stuck in a 302 redirect loop alternating between

/auth/anonymous?nextUrl=%2Fapp%2Fkibana

and

/app/kibana

Chrome aborts with ERR_TOO_MANY_REDIRECTS.

However if I enter the URL of the link (http://kibana.corp.int/app/kibana#) directly in the address bar (or follow a bookmark), the link works fine.

Could this be related to Searchguard?

Tomas_Hellberg · February 16, 2019, 11:02am

Could this be related to the “Kibana Spaces” function? I’ve tried to disable spaces, but the problem persists.

···

On Friday, 15 February 2019 23:10:21 UTC+1, Tomas Hellberg wrote:

I’ve done some more testing now and I’ve reproduced this in a local Docker environment.

If I set “anonymous_auth_enabled: false”, I instead end up on the login page every time I click on a HTML link to Kibana:

/login?nextUrl=%2Fapp%2Fkibana#?_g=()

This happens even if I’m already logged in, so there is some kind of authentication problem I guess. Maybe some authentication token that is not passed on correctly?

On Wednesday, 6 February 2019 20:12:50 UTC+1, Jochen Kressin wrote:

Ok thanks. So far we were not able to reproduce this. Just to make sure, you have anonymous auth also enabled in sg_config.ym right?

https://docs.search-guard.com/latest/anonymous-authentication

On Wednesday, February 6, 2019 at 7:51:11 PM UTC+1, Tomas Hellberg wrote:

No difference if I use / or /app/kibana#. We have anonymous access enabled, and I see no difference if I’m logged in or not. Also tried incognito mode, but same behavior.

kibana.yml

Default Kibana configuration from kibana-docker.

server.name: kibana

server.host: “0.0.0.0”

elasticsearch.url: “https://elasticsearch:9200”

elasticsearch.username: “kibanaserver”

elasticsearch.password: “kibanaserver”

elasticsearch.ssl.verificationMode: none

elasticsearch.requestHeadersWhitelist: [“Authorization”, “sgtenant”]

xpack.monitoring.ui.container.elasticsearch.enabled: true

xpack.security.enabled: false

xpack.reporting.queue.timeout: 600000

searchguard.auth.anonymous_auth_enabled: true

searchguard.auth.type: “basicauth”

searchguard.basicauth.forbidden_usernames: [“kibanaserver”, “logstash”]

searchguard.basicauth.login.title: “Welcome to Kibana and Elasticsearch”

searchguard.basicauth.login.subtitle: “This Elasticsearch cluster is managed by the CI team”

kibana.index: KIBANA_INDEX

xpack.spaces.enabled: true

elasticsearch.yml

cluster.name: “docker-cluster”

bootstrap.memory_lock: true

action.destructive_requires_name: true

xpack.monitoring.collection.enabled: true

xpack.security.enabled: false

node.master: true

node.name: “node-001”

network.publish_host: “10.33.14.74”

node.name: “node-002”

network.publish_host: “10.33.9.91”

node.name: “node-003”

network.publish_host: “10.33.9.92”

node.name: “node-004”

network.publish_host: “10.33.9.93”

reindex.remote.whitelist: “.int:”

http.port: 9200

transport.tcp.port: 9300

network.host: “0.0.0.0”

https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html#split-brain

discovery.zen.minimum_master_nodes: 3

discovery.zen.hosts_provider: file

path.repo: [“/backup/elasticsearch”]

searchguard.enterprise_modules_enabled: false

######## Start Search Guard Demo Configuration ########

WARNING: revise all the lines below before you go into production

searchguard.ssl.transport.pemcert_filepath: esnode.pem

searchguard.ssl.transport.pemkey_filepath: esnode-key.pem

searchguard.ssl.transport.pemtrustedcas_filepath: root-ca.pem

searchguard.ssl.transport.enforce_hostname_verification: false

searchguard.ssl.http.enabled: true

searchguard.ssl.http.pemcert_filepath: esnode.pem

searchguard.ssl.http.pemkey_filepath: esnode-key.pem

searchguard.ssl.http.pemtrustedcas_filepath: root-ca.pem

searchguard.allow_unsafe_democertificates: true

searchguard.authcz.admin_dn:

CN=kirk,OU=client,O=client,L=test, C=de

searchguard.audit.type: internal_elasticsearch

searchguard.enable_snapshot_restore_privilege: true

searchguard.check_snapshot_restore_write_privileges: true

searchguard.restapi.roles_enabled: [“sg_all_access”]

cluster.routing.allocation.disk.threshold_enabled: false

node.max_local_storage_nodes: 3

######## End Search Guard Demo Configuration ########

On Wednesday, 6 February 2019 17:41:21 UTC+1, Jochen Kressin wrote:

This looks weird. At the moment I don’t see a direct connection between the behavior and the SG plugin code. IMHO the only difference between the requests is that the request that stems from the link has a referrer field, whereas the direct URL would not. But there is no place in the code where we (means SG) makes use of the referrer field.

You write that you see both:

/auth/anonymous?nextUrl=%2Fapp%2Fkibana

``

and

/app/kibana

``

Do you have anonymous authentication enabled in Kibana?

https://docs.search-guard.com/latest/kibana-authentication-anonymous

Is there any difference in the behavior if you use

http://kibana.corp.int

``

instead of

http://kibana.corp.int /app/kibana#

``

Could you post the kibana.yml and elasticsearch.yml?

Thanks!

On Wednesday, February 6, 2019 at 2:33:39 PM UTC+1, Tomas Hellberg wrote:

Since I upgraded Elastic and Kibana to 6.6.0 (and searchguard 24.1 / 18), I get in a weird 302 redirect loop when following HTML links to Kibana.

Given an HTML page with the following code

Kibana

and clicking the link “Kibana” results in the browser getting stuck in a 302 redirect loop alternating between

/auth/anonymous?nextUrl=%2Fapp%2Fkibana

and

/app/kibana

Chrome aborts with ERR_TOO_MANY_REDIRECTS.

However if I enter the URL of the link (http://kibana.corp.int/app/kibana#) directly in the address bar (or follow a bookmark), the link works fine.

Could this be related to Searchguard?

Tomas_Hellberg · February 17, 2019, 2:11pm

Some more information:

After clicking an HTML link to Kibana (terminating in a ERR_TOO_MANY_REDIRECTS), I am no longer logged in.
Kibana log:
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:03Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:5,“contentLength”:9},“message”:“GET /app/kibana 302 5ms - 9.0B”}
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:04Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/auth/anonymous?nextUrl=%2Fapp%2Fkibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:21,“contentLength”:9},“message”:“GET /auth/anonymous?nextUrl=%2Fapp%2Fkibana 302 21ms - 9.0B”}
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:04Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:3,“contentLength”:9},“message”:“GET /app/kibana 302 3ms - 9.0B”}

… loop continues
Right-clicking an HTML link to Kibana and using “open link in new tab” works and Kibana loads as expected.
Kibana log:
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T13:59:22Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:200,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:200,“responseTime”:50,“contentLength”:9},“message”:“GET /app/kibana 200 50ms - 9.0B”}

jkressin · February 18, 2019, 9:40am

Unfortunately, we still cannot reproduce the behavior by any means, nor did we encounter this before. The redirects/request flow you posted seems correct to me. If you enable anonymous auth the following happens:

A request is made to Kibana (first step from your logs)
The plugin detects that there is no session cookie, and anon auth is enabled.
The plugin redirects with a 302 to the anonymous authentication endpoint (step2 from your logs)
The endpoint will perform the anonymous login. If anything goes wrong, it redirects to a static error page.
On successful authentication, the plugin writes the session cookie and redirects to the initially requested URL (step 3 from your logs)
The plugin now checks the session credentials for each request and adds them to all calls to Elasticsearch

In theory, the redirect loop cannot happen The only way I can think of is if there are any issues with writing the cookie (step 6). In this case, the plugin would set the cookie, redirect to Kibana, the cookie cannot be read and anon auth is performed again.

However, I cannot connect this with direct Kibana access versus clicking on a link. It is especially weird that it does not work if you open the link in the same window, while it does work if you open it in another window. I don’t see how that would change the behavior since the two HTTP requests should be absolutely identical.

So I guess one thing to check is if there are any differences between those two requests. Can you use your browsers developer tools / network tools and inspect the two requests? Can you compare all aspects, including the HTTP headers, to see if there are any differences?

Also, in the case when you run into the redirect loop, can you check which cookies are present for Kibana? Depending on whether you have multi-tenancy enabled you should see 2 or 3 cookies:

searchguard_authentication

searchguard_storage

searchguard_preferences (if you have MT enabled).

Have you checked the behavior also with different browsers and also your browsers incognito mode?

···

On Sunday, February 17, 2019 at 2:39:47 PM UTC+1, Tomas Hellberg wrote:

Some more information:

After clicking an HTML link to Kibana (terminating in a ERR_TOO_MANY_REDIRECTS), I am no longer logged in.
Kibana log:
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:03Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:5,“contentLength”:9},“message”:“GET /app/kibana 302 5ms - 9.0B”}
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:04Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/auth/anonymous?nextUrl=%2Fapp%2Fkibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:21,“contentLength”:9},“message”:“GET /auth/anonymous?nextUrl=%2Fapp%2Fkibana 302 21ms - 9.0B”}
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:04Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:3,“contentLength”:9},“message”:“GET /app/kibana 302 3ms - 9.0B”}

… loop continues

Right-clicking an HTML link to Kibana and using “open link in new tab” works and Kibana loads as expected.
Kibana log:
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T13:59:22Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:200,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:200,“responseTime”:50,“contentLength”:9},“message”:“GET /app/kibana 200 50ms - 9.0B”}

Tomas_Hellberg · February 18, 2019, 10:28am

Incognito mode makes no difference and the problems exists on different browsers (although Microsoft Edge does not work with “open in new tab”). Also, note that entering the link directly in the address bar always works (it doesn’t have to be a new window).

In the steps that you described, I’m curious about how step 2 works when I’m logged in and already authenticated. Whenever I click an HTML link I get logged out, so step 2 somehow doesn’t detect my session cookie. Any clue to what might cause this?

(I will see if I can get something more useful from developer tools, including cookies.)

···

On Monday, 18 February 2019 10:40:22 UTC+1, Jochen Kressin wrote:

Unfortunately, we still cannot reproduce the behavior by any means, nor did we encounter this before. The redirects/request flow you posted seems correct to me. If you enable anonymous auth the following happens:

A request is made to Kibana (first step from your logs)

The plugin detects that there is no session cookie, and anon auth is enabled.

The plugin redirects with a 302 to the anonymous authentication endpoint (step2 from your logs)

The endpoint will perform the anonymous login. If anything goes wrong, it redirects to a static error page.

On successful authentication, the plugin writes the session cookie and redirects to the initially requested URL (step 3 from your logs)

The plugin now checks the session credentials for each request and adds them to all calls to Elasticsearch

In theory, the redirect loop cannot happen The only way I can think of is if there are any issues with writing the cookie (step 6). In this case, the plugin would set the cookie, redirect to Kibana, the cookie cannot be read and anon auth is performed again.

However, I cannot connect this with direct Kibana access versus clicking on a link. It is especially weird that it does not work if you open the link in the same window, while it does work if you open it in another window. I don’t see how that would change the behavior since the two HTTP requests should be absolutely identical.

So I guess one thing to check is if there are any differences between those two requests. Can you use your browsers developer tools / network tools and inspect the two requests? Can you compare all aspects, including the HTTP headers, to see if there are any differences?

Also, in the case when you run into the redirect loop, can you check which cookies are present for Kibana? Depending on whether you have multi-tenancy enabled you should see 2 or 3 cookies:

searchguard_authentication

searchguard_storage

searchguard_preferences (if you have MT enabled).

Have you checked the behavior also with different browsers and also your browsers incognito mode?

On Sunday, February 17, 2019 at 2:39:47 PM UTC+1, Tomas Hellberg wrote:

Some more information:

After clicking an HTML link to Kibana (terminating in a ERR_TOO_MANY_REDIRECTS), I am no longer logged in.
Kibana log:
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:03Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:5,“contentLength”:9},“message”:“GET /app/kibana 302 5ms - 9.0B”}
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:04Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/auth/anonymous?nextUrl=%2Fapp%2Fkibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:21,“contentLength”:9},“message”:“GET /auth/anonymous?nextUrl=%2Fapp%2Fkibana 302 21ms - 9.0B”}
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:04Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:3,“contentLength”:9},“message”:“GET /app/kibana 302 3ms - 9.0B”}

… loop continues

Right-clicking an HTML link to Kibana and using “open link in new tab” works and Kibana loads as expected.
Kibana log:
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T13:59:22Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:200,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:200,“responseTime”:50,“contentLength”:9},“message”:“GET /app/kibana 200 50ms - 9.0B”}

Tomas_Hellberg · February 18, 2019, 11:13am

As for cookies, when stuck in the redirect loop, the developer console shows zero cookies. Then doing a reload of the page takes me to Kibana and both cookies (searchguard_authentication and searchguard_storage) are present.

···

On Monday, 18 February 2019 11:28:28 UTC+1, Tomas Hellberg wrote:

Incognito mode makes no difference and the problems exists on different browsers (although Microsoft Edge does not work with “open in new tab”). Also, note that entering the link directly in the address bar always works (it doesn’t have to be a new window).

In the steps that you described, I’m curious about how step 2 works when I’m logged in and already authenticated. Whenever I click an HTML link I get logged out, so step 2 somehow doesn’t detect my session cookie. Any clue to what might cause this?

(I will see if I can get something more useful from developer tools, including cookies.)

On Monday, 18 February 2019 10:40:22 UTC+1, Jochen Kressin wrote:

Unfortunately, we still cannot reproduce the behavior by any means, nor did we encounter this before. The redirects/request flow you posted seems correct to me. If you enable anonymous auth the following happens:

A request is made to Kibana (first step from your logs)

The plugin detects that there is no session cookie, and anon auth is enabled.

The plugin redirects with a 302 to the anonymous authentication endpoint (step2 from your logs)

The endpoint will perform the anonymous login. If anything goes wrong, it redirects to a static error page.

On successful authentication, the plugin writes the session cookie and redirects to the initially requested URL (step 3 from your logs)

The plugin now checks the session credentials for each request and adds them to all calls to Elasticsearch

In theory, the redirect loop cannot happen The only way I can think of is if there are any issues with writing the cookie (step 6). In this case, the plugin would set the cookie, redirect to Kibana, the cookie cannot be read and anon auth is performed again.

However, I cannot connect this with direct Kibana access versus clicking on a link. It is especially weird that it does not work if you open the link in the same window, while it does work if you open it in another window. I don’t see how that would change the behavior since the two HTTP requests should be absolutely identical.

So I guess one thing to check is if there are any differences between those two requests. Can you use your browsers developer tools / network tools and inspect the two requests? Can you compare all aspects, including the HTTP headers, to see if there are any differences?

Also, in the case when you run into the redirect loop, can you check which cookies are present for Kibana? Depending on whether you have multi-tenancy enabled you should see 2 or 3 cookies:

searchguard_authentication

searchguard_storage

searchguard_preferences (if you have MT enabled).

Have you checked the behavior also with different browsers and also your browsers incognito mode?

On Sunday, February 17, 2019 at 2:39:47 PM UTC+1, Tomas Hellberg wrote:

Some more information:

After clicking an HTML link to Kibana (terminating in a ERR_TOO_MANY_REDIRECTS), I am no longer logged in.
Kibana log:
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:03Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:5,“contentLength”:9},“message”:“GET /app/kibana 302 5ms - 9.0B”}
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:04Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/auth/anonymous?nextUrl=%2Fapp%2Fkibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:21,“contentLength”:9},“message”:“GET /auth/anonymous?nextUrl=%2Fapp%2Fkibana 302 21ms - 9.0B”}
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:04Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:3,“contentLength”:9},“message”:“GET /app/kibana 302 3ms - 9.0B”}

… loop continues

Right-clicking an HTML link to Kibana and using “open link in new tab” works and Kibana loads as expected.
Kibana log:
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T13:59:22Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:200,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:200,“responseTime”:50,“contentLength”:9},“message”:“GET /app/kibana 200 50ms - 9.0B”}

Tomas_Hellberg · February 18, 2019, 2:27pm

I have attached a docker-compose setup that reproduces this problem.

$ tar xf sg-test.tar

$ cd sg-test/

$ docker-compose build

$ docker-compose up

$ cd elasticsearch/sgconfig/

$ sh upload_config.sh /path/to/sgadmin-standalone/tools/sgadmin.sh localhost

Steps to reproduce :

Click an HTML link to the Kibana running on localhost, port 5601: http://localhost:5601/app/kibana#/home
This will end up in the redirect loop and terminate without showing Kibana.
Copy and paste the link
This will open Kibana successfully
Login as admin/admin
Click the link again
Stuck once again in redirect loop
Notice that the session is now logged out

sg-test.tar (90 KB)

···

On Monday, 18 February 2019 10:40:22 UTC+1, Jochen Kressin wrote:

Unfortunately, we still cannot reproduce the behavior by any means, nor did we encounter this before. The redirects/request flow you posted seems correct to me. If you enable anonymous auth the following happens:

A request is made to Kibana (first step from your logs)

The plugin detects that there is no session cookie, and anon auth is enabled.

The plugin redirects with a 302 to the anonymous authentication endpoint (step2 from your logs)

The endpoint will perform the anonymous login. If anything goes wrong, it redirects to a static error page.

On successful authentication, the plugin writes the session cookie and redirects to the initially requested URL (step 3 from your logs)

The plugin now checks the session credentials for each request and adds them to all calls to Elasticsearch

In theory, the redirect loop cannot happen The only way I can think of is if there are any issues with writing the cookie (step 6). In this case, the plugin would set the cookie, redirect to Kibana, the cookie cannot be read and anon auth is performed again.

However, I cannot connect this with direct Kibana access versus clicking on a link. It is especially weird that it does not work if you open the link in the same window, while it does work if you open it in another window. I don’t see how that would change the behavior since the two HTTP requests should be absolutely identical.

So I guess one thing to check is if there are any differences between those two requests. Can you use your browsers developer tools / network tools and inspect the two requests? Can you compare all aspects, including the HTTP headers, to see if there are any differences?

Also, in the case when you run into the redirect loop, can you check which cookies are present for Kibana? Depending on whether you have multi-tenancy enabled you should see 2 or 3 cookies:

searchguard_authentication

searchguard_storage

searchguard_preferences (if you have MT enabled).

Have you checked the behavior also with different browsers and also your browsers incognito mode?

On Sunday, February 17, 2019 at 2:39:47 PM UTC+1, Tomas Hellberg wrote:

Some more information:

After clicking an HTML link to Kibana (terminating in a ERR_TOO_MANY_REDIRECTS), I am no longer logged in.
Kibana log:
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:03Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:5,“contentLength”:9},“message”:“GET /app/kibana 302 5ms - 9.0B”}
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:04Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/auth/anonymous?nextUrl=%2Fapp%2Fkibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:21,“contentLength”:9},“message”:“GET /auth/anonymous?nextUrl=%2Fapp%2Fkibana 302 21ms - 9.0B”}
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:04Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:3,“contentLength”:9},“message”:“GET /app/kibana 302 3ms - 9.0B”}

… loop continues

Right-clicking an HTML link to Kibana and using “open link in new tab” works and Kibana loads as expected.
Kibana log:
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T13:59:22Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:200,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:200,“responseTime”:50,“contentLength”:9},“message”:“GET /app/kibana 200 50ms - 9.0B”}

jkressin · February 18, 2019, 4:52pm

Thanks for providing this. While it is still unclear what caused the problem at least we can reproduce it now. Just to make the picture complete: Does the effect only happen when starting ES and KI in Docker, or also when you try to run it on a local machine. If the first is the case it is probably related to cookes and hostnames.

···

On Monday, February 18, 2019 at 1:33:56 PM UTC+1, Tomas Hellberg wrote:

I have attached a docker-compose setup that reproduces this problem.

$ tar xf sg-test.tar

$ cd sg-test/

$ docker-compose build

$ docker-compose up

$ cd elasticsearch/sgconfig/

$ sh upload_config.sh /path/to/sgadmin-standalone/tools/sgadmin.sh localhost

Steps to reproduce :

Click an HTML link to the Kibana running on localhost, port 5601: http://localhost:5601/app/kibana#/home
This will end up in the redirect loop and terminate without showing Kibana.

Copy and paste the link
This will open Kibana successfully

Login as admin/admin

Click the link again
Stuck once again in redirect loop
Notice that the session is now logged out

On Monday, 18 February 2019 10:40:22 UTC+1, Jochen Kressin wrote:

Unfortunately, we still cannot reproduce the behavior by any means, nor did we encounter this before. The redirects/request flow you posted seems correct to me. If you enable anonymous auth the following happens:

A request is made to Kibana (first step from your logs)

The plugin detects that there is no session cookie, and anon auth is enabled.

The plugin redirects with a 302 to the anonymous authentication endpoint (step2 from your logs)

The endpoint will perform the anonymous login. If anything goes wrong, it redirects to a static error page.

On successful authentication, the plugin writes the session cookie and redirects to the initially requested URL (step 3 from your logs)

The plugin now checks the session credentials for each request and adds them to all calls to Elasticsearch

In theory, the redirect loop cannot happen The only way I can think of is if there are any issues with writing the cookie (step 6). In this case, the plugin would set the cookie, redirect to Kibana, the cookie cannot be read and anon auth is performed again.

However, I cannot connect this with direct Kibana access versus clicking on a link. It is especially weird that it does not work if you open the link in the same window, while it does work if you open it in another window. I don’t see how that would change the behavior since the two HTTP requests should be absolutely identical.

So I guess one thing to check is if there are any differences between those two requests. Can you use your browsers developer tools / network tools and inspect the two requests? Can you compare all aspects, including the HTTP headers, to see if there are any differences?

Also, in the case when you run into the redirect loop, can you check which cookies are present for Kibana? Depending on whether you have multi-tenancy enabled you should see 2 or 3 cookies:

searchguard_authentication

searchguard_storage

searchguard_preferences (if you have MT enabled).

Have you checked the behavior also with different browsers and also your browsers incognito mode?

On Sunday, February 17, 2019 at 2:39:47 PM UTC+1, Tomas Hellberg wrote:

Some more information:

After clicking an HTML link to Kibana (terminating in a ERR_TOO_MANY_REDIRECTS), I am no longer logged in.
Kibana log:
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:03Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:5,“contentLength”:9},“message”:“GET /app/kibana 302 5ms - 9.0B”}
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:04Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/auth/anonymous?nextUrl=%2Fapp%2Fkibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:21,“contentLength”:9},“message”:“GET /auth/anonymous?nextUrl=%2Fapp%2Fkibana 302 21ms - 9.0B”}
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:04Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:3,“contentLength”:9},“message”:“GET /app/kibana 302 3ms - 9.0B”}

… loop continues

Right-clicking an HTML link to Kibana and using “open link in new tab” works and Kibana loads as expected.
Kibana log:
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T13:59:22Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:200,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:200,“responseTime”:50,“contentLength”:9},“message”:“GET /app/kibana 200 50ms - 9.0B”}

jkressin · February 18, 2019, 7:52pm

Hi.

first thanks for your patience and input on this issue, highly appreciated! Based on the setup you provided we have dug into the issue deeper and think we have found the reason why this is happening. It is most likely connected to a combination of node modules that have been upgraded by Elastic from Kibana 6.5.x → 6.6.x. The effect is that the authentication cookie is not properly set when using anon auth in combination with a link that comes from a domain other than Kibana. Which then leads to the redirect loop. We are working on a fix and will provide you with a snapshot soon until the fix has made it into the next official Kibana release.

···

On Monday, February 18, 2019 at 5:52:31 PM UTC+1, Jochen Kressin wrote:

Thanks for providing this. While it is still unclear what caused the problem at least we can reproduce it now. Just to make the picture complete: Does the effect only happen when starting ES and KI in Docker, or also when you try to run it on a local machine. If the first is the case it is probably related to cookes and hostnames.

On Monday, February 18, 2019 at 1:33:56 PM UTC+1, Tomas Hellberg wrote:

I have attached a docker-compose setup that reproduces this problem.

$ tar xf sg-test.tar

$ cd sg-test/

$ docker-compose build

$ docker-compose up

$ cd elasticsearch/sgconfig/

$ sh upload_config.sh /path/to/sgadmin-standalone/tools/sgadmin.sh localhost

Steps to reproduce :

Click an HTML link to the Kibana running on localhost, port 5601: http://localhost:5601/app/kibana#/home
This will end up in the redirect loop and terminate without showing Kibana.

Copy and paste the link
This will open Kibana successfully

Login as admin/admin

Click the link again
Stuck once again in redirect loop
Notice that the session is now logged out

On Monday, 18 February 2019 10:40:22 UTC+1, Jochen Kressin wrote:

Unfortunately, we still cannot reproduce the behavior by any means, nor did we encounter this before. The redirects/request flow you posted seems correct to me. If you enable anonymous auth the following happens:

A request is made to Kibana (first step from your logs)

The plugin detects that there is no session cookie, and anon auth is enabled.

The plugin redirects with a 302 to the anonymous authentication endpoint (step2 from your logs)

The endpoint will perform the anonymous login. If anything goes wrong, it redirects to a static error page.

On successful authentication, the plugin writes the session cookie and redirects to the initially requested URL (step 3 from your logs)

The plugin now checks the session credentials for each request and adds them to all calls to Elasticsearch

In theory, the redirect loop cannot happen The only way I can think of is if there are any issues with writing the cookie (step 6). In this case, the plugin would set the cookie, redirect to Kibana, the cookie cannot be read and anon auth is performed again.

However, I cannot connect this with direct Kibana access versus clicking on a link. It is especially weird that it does not work if you open the link in the same window, while it does work if you open it in another window. I don’t see how that would change the behavior since the two HTTP requests should be absolutely identical.

So I guess one thing to check is if there are any differences between those two requests. Can you use your browsers developer tools / network tools and inspect the two requests? Can you compare all aspects, including the HTTP headers, to see if there are any differences?

Also, in the case when you run into the redirect loop, can you check which cookies are present for Kibana? Depending on whether you have multi-tenancy enabled you should see 2 or 3 cookies:

searchguard_authentication

searchguard_storage

searchguard_preferences (if you have MT enabled).

Have you checked the behavior also with different browsers and also your browsers incognito mode?

On Sunday, February 17, 2019 at 2:39:47 PM UTC+1, Tomas Hellberg wrote:

Some more information:

After clicking an HTML link to Kibana (terminating in a ERR_TOO_MANY_REDIRECTS), I am no longer logged in.
Kibana log:
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:03Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:5,“contentLength”:9},“message”:“GET /app/kibana 302 5ms - 9.0B”}
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:04Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/auth/anonymous?nextUrl=%2Fapp%2Fkibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:21,“contentLength”:9},“message”:“GET /auth/anonymous?nextUrl=%2Fapp%2Fkibana 302 21ms - 9.0B”}
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:04Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:3,“contentLength”:9},“message”:“GET /app/kibana 302 3ms - 9.0B”}

… loop continues

Right-clicking an HTML link to Kibana and using “open link in new tab” works and Kibana loads as expected.
Kibana log:
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T13:59:22Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:200,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:200,“responseTime”:50,“contentLength”:9},“message”:“GET /app/kibana 200 50ms - 9.0B”}

Tomas_Hellberg · February 18, 2019, 7:56pm

Thanks! This is so great to hear.

Also regarding you question if this only happens in Docker: We run Elastic in Docker in production, so we’ve never tested it outside Docker.

···

On Monday, 18 February 2019 20:52:21 UTC+1, Jochen Kressin wrote:

Hi.

first thanks for your patience and input on this issue, highly appreciated! Based on the setup you provided we have dug into the issue deeper and think we have found the reason why this is happening. It is most likely connected to a combination of node modules that have been upgraded by Elastic from Kibana 6.5.x → 6.6.x. The effect is that the authentication cookie is not properly set when using anon auth in combination with a link that comes from a domain other than Kibana. Which then leads to the redirect loop. We are working on a fix and will provide you with a snapshot soon until the fix has made it into the next official Kibana release.

On Monday, February 18, 2019 at 5:52:31 PM UTC+1, Jochen Kressin wrote:

Thanks for providing this. While it is still unclear what caused the problem at least we can reproduce it now. Just to make the picture complete: Does the effect only happen when starting ES and KI in Docker, or also when you try to run it on a local machine. If the first is the case it is probably related to cookes and hostnames.

On Monday, February 18, 2019 at 1:33:56 PM UTC+1, Tomas Hellberg wrote:

I have attached a docker-compose setup that reproduces this problem.

$ tar xf sg-test.tar

$ cd sg-test/

$ docker-compose build

$ docker-compose up

$ cd elasticsearch/sgconfig/

$ sh upload_config.sh /path/to/sgadmin-standalone/tools/sgadmin.sh localhost

Steps to reproduce :

Click an HTML link to the Kibana running on localhost, port 5601: http://localhost:5601/app/kibana#/home
This will end up in the redirect loop and terminate without showing Kibana.

Copy and paste the link
This will open Kibana successfully

Login as admin/admin

Click the link again
Stuck once again in redirect loop
Notice that the session is now logged out

On Monday, 18 February 2019 10:40:22 UTC+1, Jochen Kressin wrote:

Unfortunately, we still cannot reproduce the behavior by any means, nor did we encounter this before. The redirects/request flow you posted seems correct to me. If you enable anonymous auth the following happens:

A request is made to Kibana (first step from your logs)

The plugin detects that there is no session cookie, and anon auth is enabled.

The plugin redirects with a 302 to the anonymous authentication endpoint (step2 from your logs)

The endpoint will perform the anonymous login. If anything goes wrong, it redirects to a static error page.

On successful authentication, the plugin writes the session cookie and redirects to the initially requested URL (step 3 from your logs)

The plugin now checks the session credentials for each request and adds them to all calls to Elasticsearch

In theory, the redirect loop cannot happen The only way I can think of is if there are any issues with writing the cookie (step 6). In this case, the plugin would set the cookie, redirect to Kibana, the cookie cannot be read and anon auth is performed again.

However, I cannot connect this with direct Kibana access versus clicking on a link. It is especially weird that it does not work if you open the link in the same window, while it does work if you open it in another window. I don’t see how that would change the behavior since the two HTTP requests should be absolutely identical.

So I guess one thing to check is if there are any differences between those two requests. Can you use your browsers developer tools / network tools and inspect the two requests? Can you compare all aspects, including the HTTP headers, to see if there are any differences?

Also, in the case when you run into the redirect loop, can you check which cookies are present for Kibana? Depending on whether you have multi-tenancy enabled you should see 2 or 3 cookies:

searchguard_authentication

searchguard_storage

searchguard_preferences (if you have MT enabled).

Have you checked the behavior also with different browsers and also your browsers incognito mode?

On Sunday, February 17, 2019 at 2:39:47 PM UTC+1, Tomas Hellberg wrote:

Some more information:

After clicking an HTML link to Kibana (terminating in a ERR_TOO_MANY_REDIRECTS), I am no longer logged in.
Kibana log:
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:03Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:5,“contentLength”:9},“message”:“GET /app/kibana 302 5ms - 9.0B”}
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:04Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/auth/anonymous?nextUrl=%2Fapp%2Fkibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:21,“contentLength”:9},“message”:“GET /auth/anonymous?nextUrl=%2Fapp%2Fkibana 302 21ms - 9.0B”}
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:04Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:3,“contentLength”:9},“message”:“GET /app/kibana 302 3ms - 9.0B”}

… loop continues

Right-clicking an HTML link to Kibana and using “open link in new tab” works and Kibana loads as expected.
Kibana log:
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T13:59:22Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:200,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:200,“responseTime”:50,“contentLength”:9},“message”:“GET /app/kibana 200 50ms - 9.0B”}

jkressin · February 21, 2019, 10:08am

We have just released a new version 18.1 for Kibana 6.6.0 and 6.6.1 which hopefully fixes your issue:

https://docs.search-guard.com/latest/search-guard-versions

(Corresponding PR: https://github.com/floragunncom/search-guard-kibana-plugin/pull/173)

···

On Monday, February 18, 2019 at 8:56:39 PM UTC+1, Tomas Hellberg wrote:

Thanks! This is so great to hear.

Also regarding you question if this only happens in Docker: We run Elastic in Docker in production, so we’ve never tested it outside Docker.

On Monday, 18 February 2019 20:52:21 UTC+1, Jochen Kressin wrote:

Hi.

first thanks for your patience and input on this issue, highly appreciated! Based on the setup you provided we have dug into the issue deeper and think we have found the reason why this is happening. It is most likely connected to a combination of node modules that have been upgraded by Elastic from Kibana 6.5.x → 6.6.x. The effect is that the authentication cookie is not properly set when using anon auth in combination with a link that comes from a domain other than Kibana. Which then leads to the redirect loop. We are working on a fix and will provide you with a snapshot soon until the fix has made it into the next official Kibana release.

On Monday, February 18, 2019 at 5:52:31 PM UTC+1, Jochen Kressin wrote:

Thanks for providing this. While it is still unclear what caused the problem at least we can reproduce it now. Just to make the picture complete: Does the effect only happen when starting ES and KI in Docker, or also when you try to run it on a local machine. If the first is the case it is probably related to cookes and hostnames.

On Monday, February 18, 2019 at 1:33:56 PM UTC+1, Tomas Hellberg wrote:

I have attached a docker-compose setup that reproduces this problem.

$ tar xf sg-test.tar

$ cd sg-test/

$ docker-compose build

$ docker-compose up

$ cd elasticsearch/sgconfig/

$ sh upload_config.sh /path/to/sgadmin-standalone/tools/sgadmin.sh localhost

Steps to reproduce :

Click an HTML link to the Kibana running on localhost, port 5601: http://localhost:5601/app/kibana#/home
This will end up in the redirect loop and terminate without showing Kibana.

Copy and paste the link
This will open Kibana successfully

Login as admin/admin

Click the link again
Stuck once again in redirect loop
Notice that the session is now logged out

On Monday, 18 February 2019 10:40:22 UTC+1, Jochen Kressin wrote:

Unfortunately, we still cannot reproduce the behavior by any means, nor did we encounter this before. The redirects/request flow you posted seems correct to me. If you enable anonymous auth the following happens:

A request is made to Kibana (first step from your logs)

The plugin detects that there is no session cookie, and anon auth is enabled.

The plugin redirects with a 302 to the anonymous authentication endpoint (step2 from your logs)

The endpoint will perform the anonymous login. If anything goes wrong, it redirects to a static error page.

On successful authentication, the plugin writes the session cookie and redirects to the initially requested URL (step 3 from your logs)

The plugin now checks the session credentials for each request and adds them to all calls to Elasticsearch

In theory, the redirect loop cannot happen The only way I can think of is if there are any issues with writing the cookie (step 6). In this case, the plugin would set the cookie, redirect to Kibana, the cookie cannot be read and anon auth is performed again.

However, I cannot connect this with direct Kibana access versus clicking on a link. It is especially weird that it does not work if you open the link in the same window, while it does work if you open it in another window. I don’t see how that would change the behavior since the two HTTP requests should be absolutely identical.

So I guess one thing to check is if there are any differences between those two requests. Can you use your browsers developer tools / network tools and inspect the two requests? Can you compare all aspects, including the HTTP headers, to see if there are any differences?

Also, in the case when you run into the redirect loop, can you check which cookies are present for Kibana? Depending on whether you have multi-tenancy enabled you should see 2 or 3 cookies:

searchguard_authentication

searchguard_storage

searchguard_preferences (if you have MT enabled).

Have you checked the behavior also with different browsers and also your browsers incognito mode?

On Sunday, February 17, 2019 at 2:39:47 PM UTC+1, Tomas Hellberg wrote:

Some more information:

After clicking an HTML link to Kibana (terminating in a ERR_TOO_MANY_REDIRECTS), I am no longer logged in.
Kibana log:
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:03Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:5,“contentLength”:9},“message”:“GET /app/kibana 302 5ms - 9.0B”}
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:04Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/auth/anonymous?nextUrl=%2Fapp%2Fkibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:21,“contentLength”:9},“message”:“GET /auth/anonymous?nextUrl=%2Fapp%2Fkibana 302 21ms - 9.0B”}
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:04Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:3,“contentLength”:9},“message”:“GET /app/kibana 302 3ms - 9.0B”}

… loop continues

Right-clicking an HTML link to Kibana and using “open link in new tab” works and Kibana loads as expected.
Kibana log:
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T13:59:22Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:200,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:200,“responseTime”:50,“contentLength”:9},“message”:“GET /app/kibana 200 50ms - 9.0B”}

Tomas_Hellberg · February 21, 2019, 2:50pm

Thanks! I can confirm that the problem has been fixed.

···

On Thursday, 21 February 2019 11:06:45 UTC+1, Jochen Kressin wrote:

We have just released a new version 18.1 for Kibana 6.6.0 and 6.6.1 which hopefully fixes your issue:

https://docs.search-guard.com/latest/search-guard-versions

Thanks! This is so great to hear.

Also regarding you question if this only happens in Docker: We run Elastic in Docker in production, so we’ve never tested it outside Docker.

On Monday, 18 February 2019 20:52:21 UTC+1, Jochen Kressin wrote:

Hi.

first thanks for your patience and input on this issue, highly appreciated! Based on the setup you provided we have dug into the issue deeper and think we have found the reason why this is happening. It is most likely connected to a combination of node modules that have been upgraded by Elastic from Kibana 6.5.x → 6.6.x. The effect is that the authentication cookie is not properly set when using anon auth in combination with a link that comes from a domain other than Kibana. Which then leads to the redirect loop. We are working on a fix and will provide you with a snapshot soon until the fix has made it into the next official Kibana release.

On Monday, February 18, 2019 at 5:52:31 PM UTC+1, Jochen Kressin wrote:

Thanks for providing this. While it is still unclear what caused the problem at least we can reproduce it now. Just to make the picture complete: Does the effect only happen when starting ES and KI in Docker, or also when you try to run it on a local machine. If the first is the case it is probably related to cookes and hostnames.

On Monday, February 18, 2019 at 1:33:56 PM UTC+1, Tomas Hellberg wrote:

I have attached a docker-compose setup that reproduces this problem.

$ tar xf sg-test.tar

$ cd sg-test/

$ docker-compose build

$ docker-compose up

$ cd elasticsearch/sgconfig/

$ sh upload_config.sh /path/to/sgadmin-standalone/tools/sgadmin.sh localhost

Steps to reproduce :

Click an HTML link to the Kibana running on localhost, port 5601: http://localhost:5601/app/kibana#/home
This will end up in the redirect loop and terminate without showing Kibana.

Copy and paste the link
This will open Kibana successfully

Login as admin/admin

Click the link again
Stuck once again in redirect loop
Notice that the session is now logged out

On Monday, 18 February 2019 10:40:22 UTC+1, Jochen Kressin wrote:

Unfortunately, we still cannot reproduce the behavior by any means, nor did we encounter this before. The redirects/request flow you posted seems correct to me. If you enable anonymous auth the following happens:

A request is made to Kibana (first step from your logs)

The plugin detects that there is no session cookie, and anon auth is enabled.

The plugin redirects with a 302 to the anonymous authentication endpoint (step2 from your logs)

The endpoint will perform the anonymous login. If anything goes wrong, it redirects to a static error page.

On successful authentication, the plugin writes the session cookie and redirects to the initially requested URL (step 3 from your logs)

The plugin now checks the session credentials for each request and adds them to all calls to Elasticsearch

In theory, the redirect loop cannot happen The only way I can think of is if there are any issues with writing the cookie (step 6). In this case, the plugin would set the cookie, redirect to Kibana, the cookie cannot be read and anon auth is performed again.

However, I cannot connect this with direct Kibana access versus clicking on a link. It is especially weird that it does not work if you open the link in the same window, while it does work if you open it in another window. I don’t see how that would change the behavior since the two HTTP requests should be absolutely identical.

So I guess one thing to check is if there are any differences between those two requests. Can you use your browsers developer tools / network tools and inspect the two requests? Can you compare all aspects, including the HTTP headers, to see if there are any differences?

Also, in the case when you run into the redirect loop, can you check which cookies are present for Kibana? Depending on whether you have multi-tenancy enabled you should see 2 or 3 cookies:

searchguard_authentication

searchguard_storage

searchguard_preferences (if you have MT enabled).

Have you checked the behavior also with different browsers and also your browsers incognito mode?

On Sunday, February 17, 2019 at 2:39:47 PM UTC+1, Tomas Hellberg wrote:

Some more information:

After clicking an HTML link to Kibana (terminating in a ERR_TOO_MANY_REDIRECTS), I am no longer logged in.
Kibana log:
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:03Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:5,“contentLength”:9},“message”:“GET /app/kibana 302 5ms - 9.0B”}
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:04Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/auth/anonymous?nextUrl=%2Fapp%2Fkibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:21,“contentLength”:9},“message”:“GET /auth/anonymous?nextUrl=%2Fapp%2Fkibana 302 21ms - 9.0B”}
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T14:05:04Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:302,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:302,“responseTime”:3,“contentLength”:9},“message”:“GET /app/kibana 302 3ms - 9.0B”}

… loop continues

Right-clicking an HTML link to Kibana and using “open link in new tab” works and Kibana loads as expected.
Kibana log:
kibana_1 | {“type”:“response”,“@timestamp”:“2019-02-17T13:59:22Z”,“tags”:,“pid”:1,“method”:“get”,“statusCode”:200,“req”:{“url”:“/app/kibana”,“method”:“get”,“headers”:{“host”:“kibana.int”,“connection”:“keep-alive”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“accept-encoding”:“gzip, deflate”,“accept-language”:“en-US,en;q=0.9”},“remoteAddress”:“10.1.22.120”,“userAgent”:“10.1.22.120”},“res”:{“statusCode”:200,“responseTime”:50,“contentLength”:9},“message”:“GET /app/kibana 200 50ms - 9.0B”}

(Corresponding PR: https://github.com/floragunncom/search-guard-kibana-plugin/pull/173)

On Monday, February 18, 2019 at 8:56:39 PM UTC+1, Tomas Hellberg wrote:

asanchez75 · August 13, 2021, 3:48pm

Hi,

I have the same problem for

ELASTIC=7.13.4
SG_VERSION=52.1.0
SG_VERSION_KIBANA=51.0.0

Do you know if this bug was also fixed for Kibana 7?
If not, where can I find the 6.x version where this bug was fixed?

Thanks

nils · August 17, 2021, 9:11am

As Search Guard 52 and Search Guard 18 are very far apart from each other, it is unlikely that this is the same bug.

Thus, in order to analyze the problem more closely, we would need to ask you to provide config files and log files.

Topic		Replies	Views
HTTP 302 Redirect Error from Kibana when starting in Kubernetes Search Guard	3	4325	May 15, 2020
302 errors, stuck in a loop of some sort Search Guard	3	1246	October 2, 2019
Search Guard Keycloak Open ID endless loop for users with a lot of groups Search Guard	3	856	January 11, 2022
Searchguard logout/login issue with nginx Search Guard	2	542	December 28, 2017
Unable to log in to Kibana after 7.10.1 upgrade Search Guard	6	1255	December 21, 2020

302 redirect loop when following HTML links to Kibana after ES upgrade to 6.6.0, Searchguard 24.1

Default Kibana configuration from kibana-docker.

node.name: “node-002”

network.publish_host: “10.33.9.91”

node.name: “node-003”

network.publish_host: “10.33.9.92”

node.name: “node-004”

network.publish_host: “10.33.9.93”

Node | Elasticsearch Guide [8.11] | Elastic

WARNING: revise all the lines below before you go into production

Default Kibana configuration from kibana-docker.

node.name: “node-002”

network.publish_host: “10.33.9.91”

node.name: “node-003”

network.publish_host: “10.33.9.92”

node.name: “node-004”

network.publish_host: “10.33.9.93”

https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html#split-brain

WARNING: revise all the lines below before you go into production

Default Kibana configuration from kibana-docker.

node.name: “node-002”

network.publish_host: “10.33.9.91”

node.name: “node-003”

network.publish_host: “10.33.9.92”

node.name: “node-004”

network.publish_host: “10.33.9.93”

https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html#split-brain

WARNING: revise all the lines below before you go into production

Default Kibana configuration from kibana-docker.

node.name: “node-002”

network.publish_host: “10.33.9.91”

node.name: “node-003”

network.publish_host: “10.33.9.92”

node.name: “node-004”

network.publish_host: “10.33.9.93”

https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html#split-brain

WARNING: revise all the lines below before you go into production

Default Kibana configuration from kibana-docker.

node.name: “node-002”

network.publish_host: “10.33.9.91”

node.name: “node-003”

network.publish_host: “10.33.9.92”

node.name: “node-004”

network.publish_host: “10.33.9.93”

https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html#split-brain

WARNING: revise all the lines below before you go into production

Related Topics