How to use Kibana API, when using ROR Kibana plugin

1

hi,

I want to use KIbana’s import API to import saved objects. But when using ROR Kibana plugin, even when I pass the authorization header in CURL, it still redirects to login page URL. How to overcome this issue?

Thanks!

1 Like
2

This is a common one, we need to make it happen for /api/.* paths at least.

3

When we import objects to other non-default Kibana spaces, the path will be /s/spacename/api/…

4

I have a build for you to test. What changes?

Normally, if you don’t have a valid cookie (obtained from /login page) you will be just redirected to /login. This is an issue for machine-to-machine requests, like beats, and other scripts that talk to Kibana’s API.

From now on, ROR will detect Kibana API requests, and if a normal auth cookie is not found, it will also try to find basic auth (or JWT), and try to authenticate the request.

This allows administrator to simply add a new block (or user) to the ACL (or to LDAP, etc) and those credentials will serve for Kibana API consumers as well.

1 Like
5

Can you provide sample ACL that can be setup specific to Kibana API access?

1 Like
6

Because there’s a variety of Elasticsearch actions you can end up triggering by the means of interacting with the Kibana API, if there’s something specific you want to allow, just create an ACL entry like this:

- name: KibanaAPIuser
  auth_key: "kibana_api_useri:pass"

Then set up your Beats agent (or custom script) to use those credentials as basic auth credentials, and observe the ES logs. You will see this “ALLOWED” log line (used for initial authentication):

[INFO ][t.b.r.a.l.AccessControlLoggingDecorator] [n1_it] ALLOWED by { name: ‘KibanaAPIuser’, policy: ALLOW, rules: [auth_key] req={ ID:1803099961-223206945#2306, TYP:RRUserMetadataRequest, CGR:Administrators, kibana_api_user, BRS:true, KDX:.kibana, ACT:cluster:ror/user_metadata/get, OA:172.17.0.1/32, XFF:null, DA:172.17.0.2/32, IDX:<N/A>, MET:GET, PTH:/_readonlyrest/metadata/current_user […]

And later, other similar “ALLOWED” lines that show any actual operations Kibana is doing on behalf of its API caller. You might then want to proceed to allow only those actions in your final ACL.

7

This is basic auth setup. So if I already had ACL for admin users who has full access to Kibana, I wouldn’t need new ACLs. Is that understanding correct?

8

Yes it’s correct. We literally added the shortcut to avoid the login screen, but the auth mechanism is the same. Instead of getting the credentials from the form we harvest them from the basic auth header of the request

9

Do you know when this will be generally available? I’d like to test as well, on ES stack version 7.8.1

1 Like
10

This enhancement has been done in new platform code (for kibana 7.9.0 onwards) and will be already available in the next version bump for these newer kibana versions.
If you need it we can port it to the old platform too though.