Create or update application privileges Added in 6.4.0

POST /_security/privilege
Api key auth Basic auth Bearer auth

To use this API, you must have one of the following privileges:

  • The manage_security cluster privilege (or a greater privilege such as all).
  • The "Manage Application Privileges" global privilege for the application being referenced in the request.

Application names are formed from a prefix, with an optional suffix that conform to the following rules:

  • The prefix must begin with a lowercase ASCII letter.
  • The prefix must contain only ASCII letters or digits.
  • The prefix must be at least 3 characters long.
  • If the suffix exists, it must begin with either a dash - or _.
  • The suffix cannot contain any of the following characters: \, /, *, ?, ", <, >, |, ,, *.
  • No part of the name can contain whitespace.

Privilege names must begin with a lowercase ASCII letter and must contain only ASCII letters and digits along with the characters _, -, and ..

Action names can contain any number of printable ASCII characters and must contain at least one of the following characters: /, *, :.

External documentation

Query parameters

  • refresh string

    If true (the default) then refresh the affected shards to make this operation visible to search, if wait_for then wait for a refresh to make this operation visible to search, if false then do nothing with refreshes.

    Values are true, false, or wait_for.

application/json

Body Required

  • * object Additional properties
    Hide * attribute Show * attribute object
    • * object Additional properties
      Hide * attributes Show * attributes object

Responses

  • 200 application/json
    Hide response attribute Show response attribute object
    • * object Additional properties
      Hide * attribute Show * attribute object
      • * object
        Hide * attribute Show * attribute object
POST /_security/privilege 
curl \
 --request POST 'http://api.example.com/_security/privilege' \
 --header "Authorization: $API_KEY" \
 --header "Content-Type: application/json" \
 --data '"{\n  \"myapp\": {\n    \"read\": {\n      \"actions\": [ \n        \"data:read/*\" , \n        \"action:login\" ],\n        \"metadata\": { \n          \"description\": \"Read access to myapp\"\n        }\n      }\n    }\n}"'
Request examples
Run `PUT /_security/privilege` to add a single application privilege. The wildcard (`*`) means that this privilege grants access to all actions that start with `data:read/`. Elasticsearch does not assign any meaning to these actions. However, if the request includes an application privilege such as `data:read/users` or `data:read/settings`, the has privileges API respects the use of a wildcard and returns `true`. 
{
  "myapp": {
    "read": {
      "actions": [ 
        "data:read/*" , 
        "action:login" ],
        "metadata": { 
          "description": "Read access to myapp"
        }
      }
    }
}
Run `PUT /_security/privilege` to add multiple application privileges. 
{
  "app01": {
    "read": {
      "actions": [ "action:login", "data:read/*" ]
    },
    "write": {
      "actions": [ "action:login", "data:write/*" ]
    }
  },
  "app02": {
    "all": {
      "actions": [ "*" ]
    }
  }
}
Response examples (200)
A successful response from `PUT /_security/privilege`. 
{
  "myapp": {
    "read": {
      "created": true 
    }
  }
}
A successful response from `PUT /_security/privilege`. The `created` property indicates whether the privileges have been created or updated. 
{
  "app02": {
    "all": {
      "created": true
    }
  },
  "app01": {
    "read": {
      "created": true
    },
    "write": {
      "created": true
    }
  }
}