Add docs for the new API keys provisioning role - #7564
Conversation
Elastic Docs AI PR menuCheck the box to run an AI review for this pull request.
Powered by GitHub Agentic Workflows and docs-actions. For more information, reach out to the docs team. |
✅ Elastic Docs Style Checker (Vale)No issues found on modified lines! The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale. |
|
Thanks @alxchalkias, I've updated the language to be slightly more generic wrt to workload credentials. It's ready for your review again. |
Co-authored-by: Samuel Nelson <samuel.nelson@elastic.co>
shainaraskas
left a comment
shainaraskas
left a comment
There was a problem hiding this comment.
some thoughts on copy and positioning for you
| **Organization owners** can create and manage API keys for the organization. They can view and revoke all API keys in the organization. | ||
|
|
||
| Members with the **Workload credentials owner** role can create API keys and can list and revoke only the API keys they created. For more information about the **Workload credentials owner** role, refer to [User roles and privileges](/deploy-manage/users-roles/cloud-organization/user-roles.md#workload-credentials-owner). |
There was a problem hiding this comment.
wonder if this would read more clearly if it was in some sort of requirements/permissions section
also note that this is referring to actors as "members" but also keys with these roles can do the same activities programmatically :) I also think we prefer users over members
|
|
||
| The roles you can assign depend on your privileges: | ||
|
|
||
| * **Organization owners** can assign any organization-level roles, cloud resource access roles, and connected cluster access roles. |
There was a problem hiding this comment.
consider: "any" without specifying, to avoid maintaining the roles in multiple places.
also we are missing the "manage workload credentials" option (it is not a role, first thing that is not part of a role)
|
|
||
|
|
||
| You can have multiple API keys for different purposes, and you can revoke them when you no longer need them. Each organization can have up to 500 active API keys. | ||
|
|
There was a problem hiding this comment.
create procedure here (API one) should prob have a grant for workload credentials in the payload
|
|
||
| * **Billing admin**: Can manage an organization’s billing details such as credit card information, subscription and invoice history. Cannot manage other organization or deployment details and properties. | ||
|
|
||
| * $$$workload-credentials-owner$$$**Workload credentials owner**: Allows the member to manage workload credentials, such as creating, listing, and revoking their own [{{ecloud}} API keys](/deploy-manage/api-keys/elastic-cloud-api-keys.md). |
There was a problem hiding this comment.
is this a role? It doesn't look like it in the ui: https://www.figma.com/design/3bjglWkjCHd0qSRRsXkGP7/API-key-self-management-for-non-org-owners?node-id=8037-9225&m=dev
I also don't think this "role name" is the copy we use anywhere else.
|
|
||
| * $$$workload-credentials-owner$$$**Workload credentials owner**: Allows the member to manage workload credentials, such as creating, listing, and revoking their own [{{ecloud}} API keys](/deploy-manage/api-keys/elastic-cloud-api-keys.md). | ||
|
|
||
| This role only adds the ability to manage credentials. It does not give the member access to any deployments or projects. To create useful credentials, such as API keys, the member also needs [cloud resource access roles](#ec_instance_access_roles) for the deployments or projects those credentials should cover. Credentials created with this role can only include roles that the member already holds on those resources. Organization owners can still view and revoke all workload credentials in the organization. |
There was a problem hiding this comment.
IMO I don't think we need to repeat this
wonder if we should front-load "limited by user's roles" (prefer user over member here), as the "this doesn't grant permissions" is secondary, especially if we consider this not exactly a role.
one gotcha is that this is not about the roles the user already holds, but instead the user's roles at key creation time. "already" implies "at workload credentials owner" grant time.
| This role only adds the ability to manage credentials. It does not give the member access to any deployments or projects. To create useful credentials, such as API keys, the member also needs [cloud resource access roles](#ec_instance_access_roles) for the deployments or projects those credentials should cover. Credentials created with this role can only include roles that the member already holds on those resources. Organization owners can still view and revoke all workload credentials in the organization. | |
| This role only adds the ability to manage credentials. It does not give the member access to any deployments or projects. To create useful credentials, such as API keys, the member also needs [cloud resource access roles](#ec_instance_access_roles) for the deployments or projects those credentials should cover. Credentials created with this role can only include roles that the member already holds on those resources. |
4 participants
Summary
Closes #1260 Adds details about a new role that allows a member to generate workload credentials to the Elastic Cloud API keys page.
Reviewer SMEs: @/nathalie-tran and @/s-nel + @/alxchalkias
Generative AI disclosure