OpenSearch/x-pack/docs/en/rest-api/security/has-privileges.asciidoc

127 lines
3.6 KiB
Plaintext
Raw Normal View History

[role="xpack"]
[[security-api-has-privileges]]
2018-12-20 13:23:28 -05:00
=== Has privileges API
++++
<titleabbrev>Has privileges</titleabbrev>
++++
[[security-api-has-privilege]]
The `has_privileges` API allows you to determine whether the logged in user has
a specified list of privileges.
[[security-api-has-privileges-request]]
==== {api-request-title}
`GET /_security/user/_has_privileges`
[[security-api-has-privileges-prereqs]]
==== {api-prereq-title}
* All users can use this API, but only to determine their own privileges.
To check the privileges of other users, you must use the run as feature. For
more information, see
{stack-ov}/run-as-privilege.html[Submitting requests on behalf of other users].
[[security-api-has-privileges-desc]]
==== {api-description-title}
For a list of the privileges that you can specify in this API,
see {stack-ov}/security-privileges.html[Security privileges].
A successful call returns a JSON structure that shows whether each specified
privilege is assigned to the user.
[[security-api-has-privileges-request-body]]
==== {api-request-body-title}
`cluster`:: (list) A list of the cluster privileges that you want to check.
`index`::
`names`::: (list) A list of indices.
`allow_restricted_indices`::: (boolean) This needs to be set to `true` (default
is `false`) if using wildcards or regexps for patterns that cover restricted
indices. Implicitly, restricted indices do not match index patterns because
restricted indices usually have limited privileges and including them in
pattern tests would render most such tests `false`. If restricted indices are
explicitly included in the `names` list, privileges will be checked against
them regardless of the value of `allow_restricted_indices`.
`privileges`::: (list) A list of the privileges that you want to check for the
specified indices.
`application`::
`application`::: (string) The name of the application.
`privileges`::: (list) A list of the privileges that you want to check for the
specified resources. May be either application privilege names, or the names of
actions that are granted by those privileges
`resources`::: (list) A list of resource names against which the privileges
should be checked
[[security-api-has-privileges-example]]
==== {api-examples-title}
The following example checks whether the current user has a specific set of
cluster, index, and application privileges:
[source,console]
--------------------------------------------------
GET /_security/user/_has_privileges
{
"cluster": [ "monitor", "manage" ],
"index" : [
{
"names": [ "suppliers", "products" ],
"privileges": [ "read" ]
},
{
"names": [ "inventory" ],
"privileges" : [ "read", "write" ]
}
],
"application": [
{
"application": "inventory_manager",
"privileges" : [ "read", "data:write/inventory" ],
"resources" : [ "product/1852563" ]
}
]
}
--------------------------------------------------
The following example output indicates which privileges the "rdeniro" user has:
[source,console-result]
--------------------------------------------------
{
"username": "rdeniro",
"has_all_requested" : false,
"cluster" : {
"monitor" : true,
"manage" : false
},
"index" : {
"suppliers" : {
"read" : true
},
"products" : {
"read" : true
},
"inventory" : {
"read" : true,
"write" : false
}
Introduce Application Privileges with support for Kibana RBAC (#32309) This commit introduces "Application Privileges" to the X-Pack security model. Application Privileges are managed within Elasticsearch, and can be tested with the _has_privileges API, but do not grant access to any actions or resources within Elasticsearch. Their purpose is to allow applications outside of Elasticsearch to represent and store their own privileges model within Elasticsearch roles. Access to manage application privileges is handled in a new way that grants permission to specific application names only. This lays the foundation for more OLS on cluster privileges, which is implemented by allowing a cluster permission to inspect not just the action being executed, but also the request to which the action is applied. To support this, a "conditional cluster privilege" is introduced, which is like the existing cluster privilege, except that it has a Predicate over the request as well as over the action name. Specifically, this adds - GET/PUT/DELETE actions for defining application level privileges - application privileges in role definitions - application privileges in the has_privileges API - changes to the cluster permission class to support checking of request objects - a new "global" element on role definition to provide cluster object level security (only for manage application privileges) - changes to `kibana_user`, `kibana_dashboard_only_user` and `kibana_system` roles to use and manage application privileges Closes #29820 Closes #31559
2018-07-24 12:34:46 -04:00
},
"application" : {
"inventory_manager" : {
"product/1852563" : {
"read": false,
"data:write/inventory": false
}
}
}
}
--------------------------------------------------
// TESTRESPONSE[s/"rdeniro"/"$body.username"/]
// TESTRESPONSE[s/: false/: true/]