grant-api-keys.asciidoc 6.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192
  1. [role="xpack"]
  2. [[security-api-grant-api-key]]
  3. === Grant API key API
  4. ++++
  5. <titleabbrev>Grant API keys</titleabbrev>
  6. ++++
  7. .New API reference
  8. [sidebar]
  9. --
  10. For the most up-to-date API details, refer to {api-es}/group/endpoint-security[Security APIs].
  11. --
  12. Creates an API key on behalf of another user.
  13. [[security-api-grant-api-key-request]]
  14. ==== {api-request-title}
  15. `POST /_security/api_key/grant`
  16. [[security-api-grant-api-key-prereqs]]
  17. ==== {api-prereq-title}
  18. * To use this API, you must have the `grant_api_key` or the `manage_api_key` cluster privilege.
  19. [[security-api-grant-api-key-desc]]
  20. ==== {api-description-title}
  21. This API is similar to <<security-api-create-api-key>>, however it creates the
  22. API key for a user that is different than the user that runs the API.
  23. The caller must have authentication credentials for the user on whose behalf
  24. the API key will be created. It is not possible to use this API to create an
  25. API key without that user's credentials.
  26. The supported user authentication credentials types are:
  27. * username and password
  28. * <<security-api-get-token, {es} access tokens>>
  29. * <<jwt-auth-realm, JWTs>>
  30. The user, for whom the authentication credentials is provided,
  31. can optionally <<run-as-privilege,"run as">> (impersonate) another user.
  32. In this case, the API key will be created on behalf of the impersonated user.
  33. This API is intended be used by applications that need to create and manage
  34. API keys for end users, but cannot guarantee that those users have permission
  35. to create API keys on their own behalf (see <<security-api-create-api-key-prereqs>>).
  36. The API keys are created by the {es} API key service, which is automatically
  37. enabled.
  38. A successful grant API key API call returns a JSON structure that contains the
  39. API key, its unique id, and its name. If applicable, it also returns expiration
  40. information for the API key in milliseconds.
  41. NOTE: By default, API keys never expire. You can specify expiration information
  42. when you create the API keys.
  43. See <<api-key-service-settings>> for configuration settings related to API key
  44. service.
  45. [[security-api-grant-api-key-request-body]]
  46. ==== {api-request-body-title}
  47. The following parameters can be specified in the body of a POST request:
  48. `access_token`::
  49. (Required*, string)
  50. The user's <<security-api-get-token, {es} access token>>, or JWT. Both <<jwt-realm-oauth2, access>> and
  51. <<jwt-realm-oidc, id>> JWT token types are supported, and they depend on the underlying JWT realm configuration.
  52. The created API key will have a point in time snapshot of permissions of the user authenticated with this token
  53. (or even more restricted permissions, see the `role_descriptors` parameter).
  54. If you specify the `access_token` grant type, this parameter is required. It is not valid with other grant types.
  55. `api_key`::
  56. (Required, object)
  57. Defines the API key.
  58. `expiration`:::
  59. (Optional, string) Expiration time for the API key. By default, API keys never
  60. expire.
  61. `name`:::
  62. (Required, string) Specifies the name for this API key.
  63. `role_descriptors`:::
  64. (Optional, object) The role descriptors for this API
  65. key. This parameter is optional. When it is not specified or is an empty array,
  66. the API key has a point in time snapshot of permissions of the specified user or
  67. access token. If you supply role descriptors, the resultant permissions are an
  68. intersection of API keys permissions and the permissions of the user or access
  69. token. The structure of a role descriptor is the same as the request for <<api-key-role-descriptors, create API keys API>>.
  70. `metadata`:::
  71. (Optional, object) Arbitrary metadata that you want to associate with the API key.
  72. It supports nested data structure.
  73. Within the `metadata` object, keys beginning with `_` are reserved for
  74. system usage.
  75. include::client-authentication.asciidoc[]
  76. `grant_type`::
  77. (Required, string)
  78. The type of grant. Supported grant types are: `access_token`,`password`.
  79. `access_token`:::
  80. In this type of grant, you must supply either an access token, that was created by the
  81. {es} token service (see <<security-api-get-token>> and <<encrypt-http-communication>>),
  82. or a <<jwt-auth-realm, JWT>> (either a JWT `access_token` or a JWT `id_token`).
  83. `password`:::
  84. In this type of grant, you must supply the user ID and password for which you
  85. want to create the API key.
  86. `password`::
  87. (Required*, string)
  88. The user's password. If you specify the `password` grant type, this parameter is
  89. required. It is not valid with other grant types.
  90. `username`::
  91. (Required*, string)
  92. The user name that identifies the user. If you specify the `password` grant type,
  93. this parameter is required. It is not valid with other grant types.
  94. `run_as`::
  95. (Optional, string)
  96. The name of the user to be <<run-as-privilege,impersonated>>.
  97. *Indicates that the setting is required in some, but not all situations.
  98. [[security-api-grant-api-key-example]]
  99. ==== {api-examples-title}
  100. [source,console]
  101. ------------------------------------------------------------
  102. POST /_security/api_key/grant
  103. {
  104. "grant_type": "password",
  105. "username" : "test_admin",
  106. "password" : "x-pack-test-password",
  107. "api_key" : {
  108. "name": "my-api-key",
  109. "expiration": "1d",
  110. "role_descriptors": {
  111. "role-a": {
  112. "cluster": ["all"],
  113. "indices": [
  114. {
  115. "names": ["index-a*"],
  116. "privileges": ["read"]
  117. }
  118. ]
  119. },
  120. "role-b": {
  121. "cluster": ["all"],
  122. "indices": [
  123. {
  124. "names": ["index-b*"],
  125. "privileges": ["all"]
  126. }
  127. ]
  128. }
  129. },
  130. "metadata": {
  131. "application": "my-application",
  132. "environment": {
  133. "level": 1,
  134. "trusted": true,
  135. "tags": ["dev", "staging"]
  136. }
  137. }
  138. }
  139. }
  140. ------------------------------------------------------------
  141. The user (`test_admin`) whose credentials are provided can "run as" another user (`test_user`).
  142. The API key will be granted to the impersonated user (`test_user`).
  143. [source,console]
  144. ------------------------------------------------------------
  145. POST /_security/api_key/grant
  146. {
  147. "grant_type": "password",
  148. "username" : "test_admin", <1>
  149. "password" : "x-pack-test-password", <2>
  150. "run_as": "test_user", <3>
  151. "api_key" : {
  152. "name": "another-api-key"
  153. }
  154. }
  155. ------------------------------------------------------------
  156. <1> The user for which the credential is provided and performs "run as".
  157. <2> Credential for the above user
  158. <3> The impersonated user for whom the API key will be created for.