grant-api-keys.asciidoc 6.2 KB

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