FORBIDDEN ACT:indices:data/read/field_caps

1

We keep getting this error when trying to view a Metricbeat visualization. We’ve searched the forum and tried various things but cannot get this to work.

[2018-03-07T12:26:51,855][INFO ][t.b.r.a.ACL ] FORBIDDEN by default req={ ID:333056557-227173481#3274, TYP:FieldCapabilitiesRequest, CGR:N/A, USR:[no basic auth header], BRS:false, ACT:indices:data/read/field_caps, OA:127.0.0.1, IDX:, MET:POST, PTH://_field_caps?fields=*&ignore_unavailable=true&allow_no_indices=false, CNT:<N/A>, HDR:Connection,Content-Length,Host, HIS:[::Kibana-access::->[groups->false]], [::KIBANA-SRV::->[auth_key_sha256->false]] }

Current config:

http.type: ssl_netty4

readonlyrest:

    ssl:
      enable: true
      keystore_file: "beats.jks"
      keystore_pass: hidden
      key_pass: hidden
      allowed_protocols: [TLSv1.2]
      allowed_ciphers: [TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]

    prompt_for_basic_auth: true

    audit_collector: true

readonlyrest:

    access_control_rules:

    # MACHINES ##################

    - name: "::KIBANA-SRV::"
      auth_key_sha256: hidden
      verbosity: error # don't log successful request

#    - name: "::workaround::"
#      groups: ["(admin)"]
#      actions: [“indices:data/read/field_caps*]
#      type: allow
#      indices: ["*"]

    - name: "::Kibana-access::"
      groups: ["(admin)"]
      kibana_access: rw
      type: allow
      indices: ["*"]

#    - name: "::Infosec::"
#      groups: ["Infosec"]
#      kibana_access: rw
#      kibana_hide_apps: ["readonlyrest_kbn", "timelion"]
#      kibana_index: ".kibana_infosec"

    # USERS TO GROUPS ############

    users:
    - username: hidden
      auth_key_sha256: hidden
      groups: ["(admin)"]

    - username: hidden
      auth_key_sha256: hidden
      groups: ["(admin)", "Personal", "Infosec"]

    - username: hidden
      auth_key_sha256: hidden
      groups: ["(admin)"]
2
  1. There is no user credentials on the request, where does it come from?
  2. There’s two times readonlyrest: in this YAML. It does not makes sense, is it a typo?
  3. What version of ROR and ES are you using? Do you use the Kibana plugin as well?
3

ES 6.2.2 RoR 1.16.16

  1. If I remove the second ‘readonlyrest:’ entry the elasticsearch log shows this repeatedly:

WARN ][t.b.r.e.SSLTransportNetty4] io.netty.handler.ssl.NotSslRecordException: not an SSL/TLS record:

  1. The field_caps error appears to trigger when I click on different visualizations in Kibana. For example: Access logs over time [Filebeat Nginx].

Kibana says:
Metrics: [object Object]: [status_exception] forbidden, with { header={ WWW-Authenticate=“Basic” } }

I can click on others and it works fine. There are no failures in the elasticsearch log.

  1. We are using the basic free elastic plugin.
4

Hi,

I can help you on this one

I almost ended the implementation with 6.2.1 (coming from 2.4), and met several stuff/change.

for now, at least for your situation, add this block on bottom of your readonlyrest.yml (before ldap defintion, if you use some)

- name: "suepertest"
  type: allow
  actions: ["indices:data/read/field_caps"]
  verbosity: info

I ll put later all my work on configuration when I will have ended (xpack was a pain also too :slight_smile:

1 Like
5

Super! It looks like that did the trick.

Current working config:

http.type: ssl_netty4

readonlyrest:

ssl:
  enable: true
  keystore_file: "beats.jks"
  keystore_pass: XXXXXXXXXXX
  key_pass: XXXXXXXXXXX
  allowed_protocols: [TLSv1.2]
  allowed_ciphers: [TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]

prompt_for_basic_auth: true

audit_collector: true

readonlyrest:

access_control_rules:

# MACHINES ##################

- name: "::KIBANA-SRV::"
  auth_key_sha256: XXXXXXXXXXX
  verbosity: error # don't log successful request

- name: "::Kibana-access-admin::"
  groups: ["(admin)"]
  kibana_access: rw
  verbosity: error

- name: "supertest"
  type: allow
  actions: ["indices:data/read/field_caps"]
  verbosity: error

# USERS TO GROUPS ############

users:
- username: XXXXXXXXXXX
  auth_key_sha256: XXXXXXXXXXX
  groups: ["(admin)"]

- username: XXXXXXXXXXX
  auth_key_sha256: XXXXXXXXXXX
  groups: ["(admin)"]

- username: XXXXXXXXXXX
  auth_key_sha256: XXXXXXXXXXX
  groups: ["(admin)"]
6

yep I have more info under hand, but need to validate everything with 6.2.x .

also, if you meet some issue with xpack (free edition) regarding monitoring of logstash, pipeline, kibana or beats, do not hesitate to write down here, I ll give more hint.

Kr,

Fred

7

Because this issue only happens if you have x-pack monitoring, right?

8

We are not running x-pack.

9

So basically you’re trying to circumvent this old Kibana issue?

10

Are we? We’re rookies with ES. RoR appears to be working with the changes Fred suggested except for the one error here:

11

That issue in Kibana was all about the fact that Kibana does not always forward the Basic Auth header to Elasticsearch. So very often you are in the situation that you have to re-enter the password while using Kibana, over and over.

A solution would be to use ROR ACL to skip authentication for some actions (I think you’re going this way).

The real solution instead would be to skip basic auth and manage user sessions with (encrypted) cookies like ROR PRO/Enterprise Kibana plugin.

Also I think at the moment with simple basic auth you have no way to log out. Right?

12

We’ve not encountered any issues with having to re-auth to Kibana.

We’ve not needed to log out yet. Closing the browser does force logout.

The prompt_for_basic_auth: true is what forces the prompt to log in?

We’re looking at the x-pack free. Does the ROR Pro/Enterprise work with that?

13

prompt_for_basic_auth is by default true, and it is necessary to let you insert the credentials in the browser’s native form to begin with.

We have experience of making x-pack monitoring work with ROR Enterprise, yes. PRO should work too.

14

yep I confirm the

prompt_for_basic_auth : true

then here , for peeps having this setting enabled and having trouble with xpack :

on top of rules, but below kibana server one, add rule for xpack monitoring user credential :

    - name: "x-pack monitoring"
      auth_key_sha1: 6fce414848684684de68d4ed68e4d47
      type: allow
      actions: ["cluster:monitor/*", "indices:data/read/*","indices:data/write/*","indices:admin/template/*","indices:admin/create", "cluster:admin/ingest/pipeline/*"]
      indices: ["<no-index>", ".monitoring-*"]
      verbosity: info

and last rules :

    - name: "just that action from localhost"
      type: allow
      actions: ["cluster:monitor/*", "cluster:admin/xpack/monitoring/*", "cluster:admin/xpack/license/*", "indices:data/read/*","indices:data/write/*", "indices:admin/create" ]
      hosts: ["127.0.0.1"]
      indices: [".monitoring-*"]
      verbosity: info
 
    - name: "field_caps stuff"
      type: allow
      actions: ["indices:data/read/field_caps"]
      hosts: ["127.0.0.1"]
      verbosity: info

hosts settings is if your kibana runs locally with the elasticsearch. change it to the right host.

here I am migrating from elk 2.4 to es 6.2.1 , and I use RoR entreprise.
for now I still have prompt_for_basic_auth : true for compatibility and testing purpose, but I will set it to false in a few.

hope it helps you.

15

Cool, a few notes!

<no-index> is obsolete

This supposes Kibana is on localhost. Might be not true in everybody’s case. Adjust accordingly.

This is by default “info”, so it’s superfluous unless you set it to “error” to limit logging some time later.

16

Cool, it smells the usecase :smile: