create-roles.asciidoc 6.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181
  1. [role="xpack"]
  2. [[security-api-put-role]]
  3. === Create or update roles API
  4. ++++
  5. <titleabbrev>Create or update roles</titleabbrev>
  6. ++++
  7. Adds and updates roles in the native realm.
  8. [[security-api-put-role-request]]
  9. ==== {api-request-title}
  10. `POST /_security/role/<name>` +
  11. `PUT /_security/role/<name>`
  12. [[security-api-put-role-prereqs]]
  13. ==== {api-prereq-title}
  14. * To use this API, you must have at least the `manage_security` cluster
  15. privilege.
  16. [[security-api-put-role-desc]]
  17. ==== {api-description-title}
  18. The role management APIs are generally the preferred way to manage roles, rather than using
  19. <<roles-management-file,file-based role management>>. The create
  20. or update roles API cannot update roles that are defined in roles files.
  21. [[security-api-put-role-path-params]]
  22. ==== {api-path-parms-title}
  23. `name`::
  24. (string) The name of the role.
  25. [[security-api-put-role-request-body]]
  26. ==== {api-request-body-title}
  27. The following parameters can be specified in the body of a PUT or POST request
  28. and pertain to adding a role:
  29. `applications`:: (list) A list of application privilege entries.
  30. `application` (required)::: (string) The name of the application to which this entry applies
  31. `privileges`::: (list) A list of strings, where each element is the name of an application
  32. privilege or action.
  33. `resources`::: (list) A list resources to which the privileges are applied.
  34. `cluster`:: (list) A list of cluster privileges. These privileges define the
  35. cluster level actions that users with this role are able to execute.
  36. `global`:: (object) An object defining global privileges. A global privilege is
  37. a form of cluster privilege that is request-aware. Support for global privileges
  38. is currently limited to the management of application privileges.
  39. This field is optional.
  40. `indices`:: (list) A list of indices permissions entries.
  41. `field_security`::: (object) The document fields that the owners of the role have
  42. read access to. For more information, see
  43. <<field-and-document-access-control>>.
  44. `names` (required)::: (list) A list of indices (or index name patterns) to which the
  45. permissions in this entry apply.
  46. `privileges`(required)::: (list) The index level privileges that the owners of the role
  47. have on the specified indices.
  48. `query`::: A search query that defines the documents the owners of the role have
  49. read access to. A document within the specified indices must match this query in
  50. order for it to be accessible by the owners of the role.
  51. `metadata`:: (object) Optional meta-data. Within the `metadata` object, keys
  52. that begin with `_` are reserved for system usage.
  53. `run_as`:: (list) A list of users that the owners of this role can impersonate.
  54. For more information, see
  55. <<run-as-privilege>>.
  56. `remote_indices`:: (list) A list of remote indices permissions entries.
  57. +
  58. --
  59. NOTE: Remote indices are effective for <<remote-clusters-api-key,remote clusters configured with the API key based model>>.
  60. They have no effect for remote clusters configured with the <<remote-clusters-cert,certificate based model>>.
  61. --
  62. `clusters` (required)::: (list) A list of cluster aliases to which the permissions
  63. in this entry apply.
  64. `field_security`::: (object) The document fields that the owners of the role have
  65. read access to. For more information, see
  66. <<field-and-document-access-control>>.
  67. `names` (required)::: (list) A list of indices (or index name patterns) on the remote clusters
  68. (specified with `clusters`) to which the permissions in this entry apply.
  69. `privileges`(required)::: (list) The index level privileges that the owners of the role
  70. have on the specified indices.
  71. `query`::: A search query that defines the documents the owners of the role have
  72. read access to. A document within the specified indices must match this query in
  73. order for it to be accessible by the owners of the role.
  74. For more information, see <<defining-roles>>.
  75. [[security-api-put-role-example]]
  76. ==== {api-examples-title}
  77. The following example adds a role called `my_admin_role`:
  78. [source,console]
  79. --------------------------------------------------
  80. POST /_security/role/my_admin_role
  81. {
  82. "cluster": ["all"],
  83. "indices": [
  84. {
  85. "names": [ "index1", "index2" ],
  86. "privileges": ["all"],
  87. "field_security" : { // optional
  88. "grant" : [ "title", "body" ]
  89. },
  90. "query": "{\"match\": {\"title\": \"foo\"}}" // optional
  91. }
  92. ],
  93. "applications": [
  94. {
  95. "application": "myapp",
  96. "privileges": [ "admin", "read" ],
  97. "resources": [ "*" ]
  98. }
  99. ],
  100. "run_as": [ "other_user" ], // optional
  101. "metadata" : { // optional
  102. "version" : 1
  103. }
  104. }
  105. --------------------------------------------------
  106. A successful call returns a JSON structure that shows whether the role has been
  107. created or updated.
  108. [source,console-result]
  109. --------------------------------------------------
  110. {
  111. "role": {
  112. "created": true <1>
  113. }
  114. }
  115. --------------------------------------------------
  116. <1> When an existing role is updated, `created` is set to false.
  117. The following example configures a role that can run SQL in JDBC:
  118. // tag::sql-queries-permission[]
  119. [source,console]
  120. --------------------------------------------------
  121. POST /_security/role/cli_or_drivers_minimal
  122. {
  123. "cluster": ["cluster:monitor/main"],
  124. "indices": [
  125. {
  126. "names": ["test"],
  127. "privileges": ["read", "indices:admin/get"]
  128. }
  129. ]
  130. }
  131. --------------------------------------------------
  132. // end::sql-queries-permission[]
  133. The following example configures a role with remote indices privileges on a remote cluster:
  134. [source,console]
  135. --------------------------------------------------
  136. POST /_security/role/role_with_remote_indices
  137. {
  138. "remote_indices": [
  139. {
  140. "clusters": [ "my_remote" ], <1>
  141. "names": ["logs*"], <2>
  142. "privileges": ["read", "read_cross_cluster", "view_index_metadata"] <3>
  143. }
  144. ]
  145. }
  146. --------------------------------------------------
  147. <1> The remote indices privileges apply to remote cluster with the alias `my_remote`.
  148. <2> Privileges are granted for indices matching pattern `logs*` on the remote cluster ( `my_remote`).
  149. <3> The actual <<privileges-list-indices,index privileges>> granted for `logs*` on `my_remote`.