Problem with whitelistedPaths

1

Hi,

I have the following kibana.yaml:

---
elasticsearch.password: xxx
elasticsearch.ssl.verificationMode: none
elasticsearch.url: https://xxx:9200
elasticsearch.username: xxx
readonlyrest_kbn.whitelistedPaths: [".*/api/status$"]
server.host: 198.19.0.2
server.port: '5601'
server.ssl.certificate: "/etc/kibana/kibana.cert"
server.ssl.enabled: true
server.ssl.key: "/etc/kibana/kibana.key"
xpack.graph.enabled: false
xpack.ml.enabled: false
xpack.monitoring.enabled: true
xpack.security.enabled: false
xpack.watcher.enabled: false

curl -v -k https://198.19.0.2:5601/api/status

gives:

< HTTP/1.1 302 Found
< location: /login
< kbn-name: kibana
< kbn-xpack-sig: xxx
< content-type: text/html; charset=utf-8
< cache-control: no-cache
< content-length: 27
< connection: close
< Date: Tue, 12 Feb 2019 09:40:47 GMT
<
* Closing connection 0
You are being redirected...

With the following line in the logs:

Feb 12 09:40:47 xxx kibana: {"type":"response","@timestamp":"2019-02-12T09:40:47Z","tags":[],"pid":28504,"method":"get","statusCode":302,"req":{"url":"/api/status","method":"get","headers":{"user-agent":"curl/7.29.0","host":"198.19.0.2:5601","accept":"*/*"},"remoteAddress":"198.19.0.2","userAgent":"198.19.0.2"},"res":{"statusCode":302,"responseTime":3,"contentLength":9},"message":"GET /api/status 302 3ms - 9.0B"}

I’ve tried several variations for the regexp, but I always get the redirect to /login.

Any ideas what could be wrong?

kind regards,
Kristof

2

Yep just verified “whitelistedPaths” does not work anymore after we fixed the “cookiePass”. Adding this to the back log

3

Simone,

is this a breakage in the 1.16.34?

This is very important for the Load Balancers to work. if possible can this be prioritized?

Thanks,
Ravikanth

4

@ravjanga, we have an engineer on this regression right now. No worries :slight_smile:

5

Is this also broken for authenticated access?

I notice that I can view the /api/status successfully in an authenticated session with Chrome. However, when I use the same credentials using curl (–user name:password) the request is redirected to /login.

6

What version of ReadonlyREST are you using @jauld? And what kibana version?

7

Hi @sscarduzio

The response to the command below is a redirect to /login. So I am unable to access the kibana api.

curl -k -u username:redacted -X POST -H 'Content-Type: application/json' -H 'kbn-xsrf: dashboard-input' https://kibana.example.com/api/saved_objects/_export -d '{"type": "objects"}'

For testing purposes, I have added very broad permissions.

  - name: "::API::"
    auth_key: username:redacted
    actions: ["*"]
    indices: ["*"]
    kibana_index: ".kibana"
    verbosity: error

Please can you let me know if the api is available when we use RoR and a example of RoR configuration for that endpoint with least privilege.

We have Kibana 5.6.9 and readonlyrest-1.17.4-pre3_es5.6.9.

8

Hi @jauld, basic auth is supported in /login, but at the moment you need send the call to /login with credentials, get the cookie and use the cookie for the other calls.

9

I have tried the following syntax in curl

curl -k -u username:redacted -c ${HOME}/.cookie.jar -H 'kbn-xsrf: dashboard-input' https://kibana.example.com/login -X POST

The cookie created has an expired date (cookie data read using Fiddler as a debugging proxy).

Response sent 72 bytes of Cookie data:
	Set-Cookie: transient_ror_kbn_jwt=; Max-Age=0; Expires=Thu, 01 Jan 1970 00:00:00 GMT

This response did not contain a P3P Header.

Do you see an error in the curl syntax?

10

I don’t see errors, but the 1970 date in set-cookie is basically the server asking the client to delete any cookies called transient_ror_kbn_jwt. You can ignore that cookie.

The cookie you are looking for is instead “rorCookie”

In my experiment I have:

curl -vvv localhost:5601/login -ukibana:kibana

returning these response headers:

< HTTP/1.1 200 OK
< kbn-name: kibana
< kbn-xpack-sig: 82c38b54f1dc3bd471eba0e285212ad9
< content-type: text/html; charset=utf-8
< cache-control: no-cache
< set-cookie: rorCookie=Fe26.27e7f9c7b9ebfdfb951e9374f5891e16cf1c92e918b2b49a5ffd56c4b2b5fef39bvNWMp7DuoT1lza4pliVfwpNMajU1Ku82O4fP_hxplx-zrvTorhZvv3QydOLU2deulFsTjRSBBTG_iRfMoV0IngUjtcuzDLXNxl-QAa3i-9-Yb-IHgHE4UBqb7ypHZE1fLP8hj6fTs0-NYvNKYZRzmMT89FN1jvngGI2W_NqGz4-PMQTW-t2DRoY5y8MB7wz21GD0FeoFWb1kF_0hW92fKfJEhJb9tYCKAyeSLa4QY7QcJ9tzQXFRpYUVHby0FWttWzmi3uUzXe29W2d7AwX850F4-4TBA_3_0Q_aVgx0CLmislcxJQevMDpkZ8fn4VwFbyeFPAsUUsmffC72e6KCCWkAqAjYFL_41exj5vKZYUsBETYZDHWERztNCT6TAJ50we6USw2BOIWzadc1zyK5eAOFZn5oNRV-HpLwOtpfZ1BsepZlNDB8WPJcnuaBKsZleaEfUGck_QAKUHGmm-C7t1431d7f0aa76058666839e100dcb0800c5bb12e4ce43086e68b2b8556a3fc7c0*dbBsiCQ0I6wtxFfp8tXiLVwnbyupD3J1gG3s1lhAJmc; Max-Age=259210; Expires=Sat, 06 Apr 2019 16:10:07 GMT; HttpOnly; Path=/
< content-length: 40
< accept-ranges: bytes
< connection: close
< Date: Wed, 03 Apr 2019 16:09:57 GMT

11

In my tests, using the same syntax, no set-cookie header is returned.

curl -vvv -k -u user:redacted https://127.0.0.1:5601/login

< HTTP/1.1 200 OK
< kbn-name: kibana
< kbn-version: 5.6.9
< kbn-xpack-sig: 14z762e75as39dfb358e88bd81b17bd8
< content-type: text/html; charset=utf-8
< cache-control: no-cache
< content-length: 11634
< accept-ranges: bytes
< Date: Thu, 04 Apr 2019 08:42:34 GMT
< Connection: keep-alive

We have some users authenticated using LDAP, if that affects behaviour, but the first entry in the RoR config has a plain auth_key and no LDAP reference. The relevant user is able to login successfully using a form based login with Chrome.

So still not able to login using basic auth.

12

Hi,

The basic auth issue is resolved.

The machine I was using for testing had an older version of the RoR plugin. The machine with the new version allows Basic auth.

With the 1.17.4-pre3 version there is no need to use a stored cookie.

Regards

1 Like