Hi,
I cannot find an answer neither in the documentation nor this forum so I would like to ask, what are the default restrictions for RW ROR users (e.g. ldap) in KBN API usage, if there are any? 
Is every KBN user able to run any available (GET|PATCH|POST|PUT|DELETE) for “kbn:/api/*”?
Hello @mikeIT
Is every KBN user able to run any available (GET|PATCH|POST|PUT|DELETE) for “kbn:/api/*”?
By default, yes, any authenticated user can call any HTTP method (GET/PUT/PATCH/POST/DELETE) against kbn:/api/*. There’s no per-method restriction applied at the Kibana proxy layer for regular RW/RO access levels.
If you need to restrict specific Kibana API endpoints for a user, that’s done via accessLevel: api_only + allowed_api_paths — see the docs: For Elasticsearch | ReadonlyREST
Okay. But is there any option to restrict e.g DELETE data_view from Space or permission for update (e.g kibana settings via api) for existing kibana.access RW LDAP users?
Okay. But is there any option to restrict e.g DELETE data_view from Space or permission for update (e.g kibana settings via api) for existing kibana.access RW LDAP users?
No, not by using allowed_api_paths mechanism, for users with kibana.access: rw. ReadonlyREST’s allowed_api_paths A mechanism is available for kibana.access: api_only, so it cannot be used to selectively deny specific Kibana API operations (such as DELETE of a data view) while keeping the user on rw access.
You can deny a specific action, see actions rule. In this case, it will be something like: (note that the forbid block must be declared before)
- name: DENY_KIBANA_SPACE_DELETE
type: forbid
auth_key: user:dev
indices:
- ".kibana*"
actions:
- "indices:data/write/delete"
- name: USER_DEFAULT
auth_key: user:dev
kibana:
access: rw
However, this will block any document deletion in the index, not just Space deletion.
Hmm, what should I understand as “any document deletion in the index”? 
Hmm, what should I understand as “any document deletion in the index”?
It means that action,
actions:
- "indices:data/write/delete"
will be performed for multiple Kibana API endpoints and Kibana UI requests, so the users won’t be able to DELETE data_view from Space and also DELETE a Data View , DELETE a saved object, DELETE a dashboard etc.
This rule blocks document-level deletion in the .kibana* index. It is not aware of the type of Kibana object being deleted, so it will affect any Kibana operation that results in an indices:data/write/delete request against that index.
I’ve just tried and test this rule “indices:data/write/delete” and as ldap rw user I was able to create and then delete data_view from the same space. Within Stack Management-‘Data Views’ I could click to delete but the view of data_views was still the same without any result. Finally, from “Saved Objects” I was still able to completely delete specific ‘data view’
could you show your settings?
I have something like these (I’ve tried indices and actions like in your example for this rule as well )
- name: "::DENY_KIBANA_DELETE::"
ldap_auth:
name: "ldap"
groups_any_of: ["XXX"]
type: forbid
indices: [".kibana*"]
actions: ["indices:data/write/delete"]
verbosity: error
and then for RW ldap user
- name: "::XX LDAP::"
ldap_auth:
name: "ldap"
groups_any_of: ["XXX"]
indices: [".kibana-*",".reporting-*", ".ds-.kibana-reporting-.kibana-*", ".kibana-reporting-*", "xxx-*"]
verbosity: error
kibana:
access: rw
type: allow
*some time ago I also tried to achieve something similiar using User access to index management - #10 by ronald.vanboven but that restriction blocked users from updating existing Visualisations and Dashboards.
Finally, from “Saved Objects” I was still able to completely delete specific ‘data view’
Looks like it’s another action and for saved object it should be defined like
actions:
- "indices:data/write/delete"
- "indices:data/write/bulk"
You can check the action for a specific request in the logs
FORBIDDEN by { name: 'DENY_KIBANA_SPACE_DELETE', policy: FORBID, rules: [auth_key, actions, indices] } req={ ID:5ee05800-1b6b-4d53-9888-be9713eb6c14-1680950695#27396, TYP:BulkRequest, CGR:<N/A>, USR:user2 (attempted), BRS:true, ACT:indices:data/write/bulk, OA:127.0.0.1/32, XFF:localhost:5601, DA:127.0.0.1/32, IDX:.kibana_analytics_9.5.2, MET:POST, PTH:/_bulk, CNT:<OMITTED, LENGTH=109.0 B> , HDR:x-forwarded-for=localhost:5601, Host=localhost:9200, x-ror-kibana-request-path=/s/default/internal/kibana/management/saved_objects/_bulk_delete, keep-alive=timeout=10, max=1000, user-agent=Kibana/9.5.2, Content-Length=109, cookie=KBN_LOCALE=en; rorCookie_saml_kc=s%3AVY7_gyuseoSwkzLwIFeEkFdYid5Jgg9l.vxT4jHZv6%2BQ6ORPCw1iH0Fb03VB5wxBlrdkHzlvWHLk; __Host-ror.x-csrf-token-MC4wLjAuMDo1NjAx-session_id=252e5d71b3f2340ec71225b940168493; __Host-ror.x-csrf-token-MC4wLjAuMDo1NjAx=6df0a37363939fbe3ac2dadc2affb60dde7b7c0a07ef9341324374e74e7d9214.e1484d332c557f94bc5de6c437da70f65893c0dc543144d7f9599fbb0094e4fcc77fa7f1c8ba7c9ac15c2b74aef7f3788e5ed6444e771105cf18a813a359b70c, accept=application/vnd.elasticsearch+json; compatible-with=9, x-ror-kibana-index=.kibana, Authorization=<OMITTED>, connection=keep-alive, x-ror-correlation-id=5ee05800-1b6b-4d53-9888-be9713eb6c14, x-opaque-id=unknownId, x-ror-tenancy=U2FsdGVkX1+awIUTl6JZH4MHr5dmmJZdnhZdU+Gi8eU3Mmf3Qctyb6hgZPiNRoa+, x-elastic-product-origin=kibana, content-type=application/vnd.elasticsearch+x-ndjson; compatible-with=9, x-ror-kibana-request-method=post, x-elastic-client-meta=es=9.4.2,js=24.19.0,t=9.3.6,hc=24.19.0, Accept-Charset=utf-8, HIS:[KIBANA_SERVER: NOT_MATCHED (AUTH_FAIL (Username mismatch)) -> RULES:[auth_key->false]], [JWT_AUTH: NOT_MATCHED (AUTH_FAIL (JWT header 'Authorization' has an invalid or unrecognized token format)) -> RULES:[jwt_auth->false]], [DENY_KIBANA_SPACE_DELETE: MATCHED -> RULES:[auth_key->true, actions->true, indices->true] RESOLVED:[user=user2;indices=.kibana_analytics_9.5.2]], }
The action for the specific request is printed in the ACT:indices:data/write/bulk part
With actions: [“indices:data/write/delete”,“indices:data/write/bulk”] I directly cannot delete data view or that one from saved objects. But “as user” I don’t see nor get any ‘popup’ with forbidden message. In “Data views” there’s still no reaction and in ‘Saved objects’ view when I try to delete one object, Kibana freezes with elasic “logo” and darker background
In both cases only in Browser’s Devtools I see:
Request URL
http://kibana_ip/kibana_instance/s/XXX/api/content_management/rpc/delete
Request Method POST
Status Code 403 Forbidden
Request URL
http://kibana_ip/kibana_instance/s/XXX/internal/kibana/management/saved_objects/_bulk_delete
Request Method POST
Status Code 403 Forbidden
Looks like Kibana UI is not able to handle a 403 status properly in this case. I will create a task to resolve this issue.