diff --git a/src/content/docs/apis/nerdgraph/examples/nerdgraph-api-secret-management-service.mdx b/src/content/docs/apis/nerdgraph/examples/nerdgraph-api-secret-management-service.mdx index 70ddc784886..0eeee717ace 100644 --- a/src/content/docs/apis/nerdgraph/examples/nerdgraph-api-secret-management-service.mdx +++ b/src/content/docs/apis/nerdgraph/examples/nerdgraph-api-secret-management-service.mdx @@ -4,7 +4,7 @@ metaDescription: "Learn how to use the Secrets management service to securely st freshnessValidatedDate: never --- -When you're working with New Relic, you might need to store sensitive information like API keys and application credentials. In New Relic, these are called secrets. The Secrets management service provides a secure way to store and retrieve these secrets in a centralized location through our [NerdGraph API](/docs/apis/nerdgraph/get-started/introduction-new-relic-nerdgraph/). +When you're working with New Relic, you might need to store sensitive information like API keys and application credentials. In New Relic, these are called secrets. The Secrets management service provides a secure way to store and retrieve these secrets in a centralized location through our [NerdGraph API](/docs/apis/nerdgraph/get-started/introduction-new-relic-nerdgraph/). @@ -12,59 +12,90 @@ You can store secrets only in string format. -The key features of the Secrets management service are: +The key features of the Secrets management service are: * **Unique keys for secrets**: You can prevent accidental exposure of secrets by assigning a unique key to each one when storing. Use the key to retrieve and manage the secrets. -* **Secrets stored at [account or organization level](/docs/accounts/accounts-billing/account-structure/new-relic-account-structure/)**: +* **Secrets stored at [account or organization level](/docs/accounts/accounts-billing/account-structure/new-relic-account-structure/)**: To access and use a secret across multiple accounts, you can store it at the organization level. If a secret is specific to a single account, you can store it at the account level. -* **Versions of secrets**: You can update a secret without losing the previous version. The Secrets management service tracks all versions of a secret. +* **Versions of secrets**: You can update a secret without losing the previous version. The Secrets management service tracks all versions of a secret. * **Controlled deletion and recovery of secrets**: The service allows recoverable deletion of secrets. Users without the Purge permission can soft-delete secrets. Permanent deletion is restricted to users with the Purge permission. +* **Standard secrets with role-based access**: Standard secrets are accessible to all users with permissions in the account or organization. Admins control access by assigning custom roles with permission levels ranging from **View** to **Purge**. -* **Access control**: Admins can define who can access the secrets by setting custom roles and permissions, and specifying the scope of permissions. The scope can range from **View** to **Purge** permissions. +* **Sharable secrets with fine-grained access**: Sharable secrets are private by default to the creator, who can grant specific permissions (read, update, delete) to individual users, groups, or system identities. Organization admins retain full access to all sharable secrets for oversight and management. ## Secrets management services billing [#secrets-management-services-billing] -The Secrets management service is an Advanced Compute Product feature offered as an [add-on](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/add-on-billing) or as a part of the Compute pricing model. Advanced [CCUs](/docs/licenses/license-information/product-definitions/new-relic-one-pricing-definitions/#compute-capacity-unit) are consumed when NerdGraph queries are executed to store, retrieve, or manage secrets. +The Secrets management service is an Advanced Compute Product feature offered as an [add-on](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/add-on-billing) or as a part of the Compute pricing model. Advanced [CCUs](/docs/licenses/license-information/product-definitions/new-relic-one-pricing-definitions/#compute-capacity-unit) are consumed when NerdGraph queries are executed to store, retrieve, or manage secrets. -## Access control[#security-and-access-control] +## Standard secrets access control [#security-and-access-control] -Users with [standard roles](/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-concepts/#standard-roles) can access the Secrets management service specific to the accounts they have access to, with the following permissions. +Users with [standard roles](/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-concepts/#standard-roles) can access the Secrets management service specific to the accounts they have access to, with the following permissions. * **Read Only**: Users can only retrieve secrets. They can't create, update, or delete secrets. * **Standard User**: Users can create, update, retrieve, and soft-delete secrets. -* **All Product Admin**: Users have full access to the Secrets management service. They can create, update, retrieve, soft-delete, permanently delete, and fetch the list of secrets. +* **All Product Admin**: Users have full access to the Secrets management service. They can create, update, retrieve, soft-delete, permanently delete, and fetch the list of secrets. * **Billing User**: Users can only fetch the list of secrets. To manage secrets at the account level with a non-standard role, ask your admin to [create a custom role](/docs/accounts/accounts-billing/new-relic-one-user-management/account-user-mgmt-tutorial/#roles) with the necessary permissions, and assign them to your user group. -For managing secrets at the organization level, ask your admin to create an [org-scoped custom role via the NerdGraph API](https://docs.newrelic.com/docs/apis/nerdgraph/examples/nerdgraph-manage-groups/#create-role), add the required permissions, and assign it to the user group. [Organization Manager](/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-concepts/#admin-settings) have default permissions at the organization level, but to allow them to manage secrets, ask your admin to assign them a custom role specific to the Secrets management service. +For managing secrets at the organization level, ask your admin to create an [org-scoped custom role via the NerdGraph API](https://docs.newrelic.com/docs/apis/nerdgraph/examples/nerdgraph-manage-groups/#create-role), add the required permissions, and assign it to the user group. [Organization Manager](/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-concepts/#admin-settings) have default permissions at the organization level, but to allow them to manage secrets, ask your admin to assign them a custom role specific to the Secrets management service. -Setup and configure the users, roles, permissions, and access to the Secrets management service at the account and organization level, in accordance with your organization policies and requirements. +Setup and configure the users, roles, permissions, and access to the Secrets management service at the account and organization level, in accordance with your organization policies and requirements. +## Sharable secrets with fine-grained access [#sharable-secrets] + +While standard secrets are accessible to all users with permissions in an account or organization, enterprises with multiple teams often need to restrict secrets to specific individuals. Sharable secrets address this need. + + +To work with sharable secrets, users must first have the base permissions described in [Standard secrets access control](#security-and-access-control). The fine-grained access permissions described below are **in addition to** those base requirements. + + +When you create a sharable secret, you automatically become its owner with full control. You can grant access to users, groups, or system identities by assigning individual permissions or by using roles that bundle multiple permissions together. + +**Individual permissions (granted on top of base access):** + +* **Read**: Retrieve the secret value +* **Update**: Change the secret value +* **Delete**: Remove the secret + +**Predefined roles (granted on top of base access):** + +* **Secret Owner**: Full control (read, update, delete, grant/revoke) +* **Secret Reader**: Read-only access + +You can also [create custom roles]((/docs/accounts/accounts-billing/new-relic-one-user-management/account-user-mgmt-tutorial/#roles)) that combine specific permissions based on your needs. Organization admins retain full access to all sharable secrets for oversight. + +When you need a synthetic monitor, workflow, or other automated process to access your secret, you grant access to its system identity. A system identity is a unique identifier assigned to each automated process in New Relic. When you link a secret to a monitor or workflow through the New Relic UI, the system identity for that automated process is used to control access at runtime. + + +Standard secrets cannot be converted into sharable secrets. To migrate an existing standard secret, create a new sharable secret with the same value, grant appropriate access, update your applications, and delete the old secret. + + ## Pre-requisites [#prerequisites] -To use the Secrets management service, you need: +To use the Secrets management service, you need: * The [Advanced Compute](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/add-on-billing) pricing plan * A [New Relic account](https://newrelic.com/signup) * Your API user key for [queries and mutations]((https://docs.newrelic.com/docs/apis/nerdgraph/get-started/introduction-new-relic-nerdgraph/#terminology)) - + * Appropriate permissions to create and manage secrets. Refer to [Standard secrets access control](#security-and-access-control) and [Sharable secrets with fine-grained access](#sharable-secrets) for details on required roles and permissions. + User type and assigned roles can affect your NerdGraph permissions. For more details, refer [Factors affecting access](https://docs.newrelic.com/docs/accounts/accounts-billing/account-structure/factors-affecting-access-features-data/#user-permissions). -## Use the Secrets management service [#use-secrets-management-service] -From the [NerdGraph Explorer](/docs/apis/nerdgraph/get-started/nerdgraph-explorer/), use [mutations and queries](/docs/accounts/accounts-billing/account-structure/factors-affecting-access-features-data/#user-permissions) to interact with the Secrets management service. +## Use the Secrets management service [#use-secrets-management-service] +From the [NerdGraph Explorer](/docs/apis/nerdgraph/get-started/nerdgraph-explorer/), use [mutations and queries](/docs/accounts/accounts-billing/account-structure/factors-affecting-access-features-data/#user-permissions) to interact with the Secrets management service. Here are the common attributes you will use in the mutations and queries: @@ -207,14 +238,25 @@ Copy your actual secret only into the `value` attribute. Ensure it is not declar ### Operations[#operations] -The operations you can perform with the Secrets management service are as follows: +The operations you can perform with the Secrets management service are organized into two categories: + + +**Choosing between standard and sharable secrets:** + +* Use **standard secrets** (`secretsManagementCreateSecret`) when you want to share a secret with all users who have access to the account or organization. +* Use **sharable secrets** (`secretsManagementCreateShareableSecret`) when you need to control exactly who can access a secret by granting permissions to specific users, groups, or system identities. + + + - -Use the `secretsManagementCreateSecret` mutation with the following parameters to store a secret. +Use the `secretsManagementCreateSecret` mutation with the following parameters to store a standard secret that will be accessible to all users with permissions in the specified account or organization. @@ -423,6 +465,253 @@ mutation { + + +Use the `secretsManagementCreateShareableSecret` mutation to create a private secret with fine-grained access control. When you create a sharable secret, you automatically become the owner with full control over who can access it. + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ **Attribute name** + + **Data type** + + **Description** +
+ `description` (Optional) + + String + + Give a description for the secret. +
+ `key` (Required) + + String + + Assign a unique key for the secret. +
+ `namespace` (Optional) + + String + + Assign a name if you want to store the secret in a specific namespace. +
+ `scope` (Required) + + + `type`: Enum + `id`: string + + + * `type`: Based on your [role](#security-and-access-control) and requirements, select `Account` or `Organization`. + * `id`: Enter the corresponding account or organization ID. +
+ `tags` (Optional) + + Array + + Assign a key and value pair. +
+ `value` (Required) + + String + + Enter the actual secret. +
+ +#### Sample query: + +```graphql +mutation { + secretsManagementCreateShareableSecret( + scope: {type: ACCOUNT, id: 1} + key: "prod-api-key" + value: "sk_live_abc123xyz" + namespace: "production" + description: "Private API key for production" + tags: [{key: "environment", value: "production"}] + ) { + scope { + type + id + } + key + namespace + latestVersion + description + tags { + key + value + } + metadata { + createdAt + updatedAt + } + } +} + +``` + + + +### Response + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ **Attribute name** + + **Description** +
+ `description` + + The description of the secret, if provided. +
+ `key` + + The assigned key. +
+ `latestVersion` + + The version of the secret. If you've created a new secret, the version will be `0`. +
+ `metadata` + + Associated metadata with the secret, including: + * `createdAt`: Timestamp when the secret was created + * `updatedAt`: Timestamp when the secret was last updated +
+ `namespace` + + The namespace of the secret, if provided. +
+ `scope` + + The account or organization ID associated with the secret. +
+ `tags` + + The key and value pair associated with the secret, if any. +
+ +#### Sample response: + + ```json + { + "data": { + "secretsManagementCreateShareableSecret": { + "scope": { + "type": "ACCOUNT", + "id": "1" + }, + "key": "prod-api-key", + "namespace": "production", + "latestVersion": 0, + "description": "Private API key for production", + "tags": [ + { + "key": "environment", + "value": "production" + } + ], + "metadata": { + "createdAt": "2025-10-30T12:34:56.789Z", + "updatedAt": "2025-10-30T12:34:56.789Z" + } + } + } +} + ``` + + +After creating a sharable secret, you become the owner automatically. To grant access to other users, groups, or system identities, use the `authorizationManagementGrantAccess` mutation. For more details, see the [Grant access to a sharable secret](#grant-access-sharable-secret) section. + + +
+ + + + `isSharable` + + + Indicates whether the secret is a [sharable secret](#sharable-secrets) with fine-grained access control. If `true`, the secret uses fine-grained permissions and is private to the creator by default. If `false`, it's a standard secret accessible to all users with permissions in the account or organization. + + `key` @@ -612,6 +909,7 @@ Use the `{customerAdministration {secret}}` query to retrieve secrets along with "customerAdministration": { "secret": { "description": "ZXY", + "isSharable": false, "key": "Test2", "namespace": null, "retrievedValue": { @@ -1666,6 +1964,10 @@ mutation { Use the `{customerAdministration {secrets}}` query to retrieve a list of secrets available in the account or organization. You can retrieve secrets that are scoped only for your current account or organization. + +The list includes all secrets in the scope, including sharable secrets you may not have permission to access. Access permissions are enforced when you retrieve the secret value using the [Retrieve a secret](#retrieve-secret) operation. + + @@ -1790,6 +2092,7 @@ Use the `{customerAdministration {secrets}}` query to retrieve a list of secrets The details of the listed secrets, including: * `description`: The description of the secret, if available. * `isDeleted`: Indicates whether the secret is in a soft-delete state or not. + * `isSharable`: Indicates whether the secret is a [sharable secret](#sharable-secrets) with fine-grained access control. * `key`: The key of the secret. * `latestVersion`: The latest version number of the secret. * `metadata`: Metadata associated with the secret, if any. @@ -1828,6 +2131,7 @@ Use the `{customerAdministration {secrets}}` query to retrieve a list of secrets { "description": "ZXY", "isDeleted": false, + "isSharable": false, "key": "test2", "latestVersion": 1, "metadata": { @@ -1840,6 +2144,7 @@ Use the `{customerAdministration {secrets}}` query to retrieve a list of secrets { "description": "XYZ", "isDeleted": false, + "isSharable": false, "key": "test2", "latestVersion": 0, "metadata": { @@ -1852,6 +2157,7 @@ Use the `{customerAdministration {secrets}}` query to retrieve a list of secrets { "description": "CBA", "isDeleted": false, + "isSharable": false, "key": "test1", "latestVersion": 1, "metadata": { @@ -1870,7 +2176,589 @@ Use the `{customerAdministration {secrets}}` query to retrieve a list of secrets - + + +After creating a sharable secret, you can grant specific permissions to users, groups, system identities, or system identity groups. Use the `authorizationManagementGrantAccess` mutation to share your secret with authorized entities. + + +The secret owner (creator), organization admins, or users with the `secret.create.grants` capability can grant access to a sharable secret. + + +#### Input attributes + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ **Attribute name** + + **Data type** + + **Description** +
+ `grantAccessOptions` (Required) + + Object + + Contains the grant configuration with two main components: + * `entityAccessGrants`: Defines the secret and the role to grant + * `grantee`: Specifies who receives access +
+ `entityAccessGrants.entity.id` (Required) + + String + + The unique ID of the secret. The format is `namespace::partition::entry_key_secret`. + + For example, if you created a secret with key `prod-api-key` in account `12345` with namespace `production`, the entity ID is: `production::account-12345::prod-api-key`. If no namespace was provided, use an empty string: `::account-12345::prod-api-key`. +
+ `entityAccessGrants.entity.type` (Required) + + String + + The entity type. For secrets, this is always `secret`. +
+ `entityAccessGrants.roleId` (Required) + + String + + The unique ID of the role to grant. To find available role IDs, use the NerdGraph API explorer to query roles with scope `secret`. Common roles include Secret Owner (full control) and Secret Reader (read-only access). +
+ `grantee.id` (Required) + + String + + The unique ID of the user, group, system identity, or system identity group receiving access. +
+ `grantee.type` (Required) + + Enum + + The type of grantee. Valid values: + * `USER`: Individual user + * `GROUP`: User group + * `SYSTEM_IDENTITY`: System identity (for automated processes) + * `SYSTEM_IDENTITY_GROUP`: System identity group +
+ +#### Sample query: + +```graphql +mutation { + authorizationManagementGrantAccess( + grantAccessOptions: { + entityAccessGrants: { + entity: { + id: "production::account-1::prod-api-key", + type: "secret" + }, + roleId: "role-id-for-secret-reader" + }, + grantee: { + id: "system-identity-id-abc123", + type: SYSTEM_IDENTITY + } + } + ) { + roles { + id + roleId + } + } +} +``` + +### Response + + + + + + + + + + + + + + +
+ **Attribute name** + + **Description** +
+ `roles` + + An array of role assignments created by the grant operation, including: + * `id`: The unique identifier of the grant + * `roleId`: The role ID that was granted +
+ +#### Sample response: + +```json +{ + "data": { + "authorizationManagementGrantAccess": { + "roles": [ + { + "id": "grant-id-xyz789", + "roleId": "role-id-for-secret-reader" + } + ] + } + } +} +``` + + +To revoke access to a sharable secret, use the `authorizationManagementRevokeAccess` mutation. + + +
+ + + +Use the `authorizationManagementRevokeAccess` mutation to remove access from users, groups, system identities, or system identity groups that were previously granted access to your sharable secret. + + +The secret owner (creator), organization admins, or users with the appropriate revoke permission can remove access to a sharable secret. + + +#### Input attributes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ **Attribute name** + + **Data type** + + **Description** +
+ `grantAccessOptions` (Required) + + Object + + Contains the revoke configuration with the same structure as the grant operation. +
+ `entityAccessGrants.entity.id` (Required) + + String + + The unique ID of the secret in the format `namespace::partition::entry_key_secret`. +
+ `entityAccessGrants.entity.type` (Required) + + String + + The entity type. For secrets, this is always `secret`. +
+ `entityAccessGrants.roleId` (Required) + + String + + The unique ID of the role to revoke. +
+ `grantee.id` (Required) + + String + + The unique ID of the user, group, system identity, or system identity group from which to revoke access. +
+ `grantee.type` (Required) + + Enum + + The type of grantee. Valid values: `USER`, `GROUP`, `SYSTEM_IDENTITY`, `SYSTEM_IDENTITY_GROUP`. +
+ +#### Sample query: + +```graphql +mutation { + authorizationManagementRevokeAccess( + grantAccessOptions: { + entityAccessGrants: { + entity: { + id: "production::account-12345::prod-api-key", + type: "secret" + } + roleId: "role-id-for-secret-reader" + } + grantee: { + id: "system-identity-id-abc123", + type: SYSTEM_IDENTITY + } + } + ) { + roles { + id + roleId + } + } +} +``` + +### Response + + + + + + + + + + + + + + +
+ **Attribute name** + + **Description** +
+ `roles` + + An array of role information related to the revoked grant. +
+ +#### Sample response: + +```json +{ + "data": { + "authorizationManagementRevokeAccess": { + "roles": [ + { + "id": "grant-id-xyz789", + "roleId": "role-id-for-secret-reader" + } + ] + } + } +} +``` + +
+ + + +Use the `customerAdministration/entityGrants` query to see which users, groups, system identities, or system identity groups have been granted access to your sharable secret. + + +This query returns only explicit grants made directly on the secret. It does not show implied access or permissions inherited from parent scopes. + + +#### Input attributes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ **Attribute name** + + **Data type** + + **Description** +
+ `iamParent.id` (Required) + + String + + The ID of the account or organization where the secret is stored. +
+ `iamParent.scope` (Required) + + Enum + + The parent scope type. Valid values: `ACCOUNT`, `ORGANIZATION`. +
+ `entity.id` (Optional) + + String + + The unique ID of the secret in the format `namespace::partition::entry_key_secret`. When provided, only grants for this specific secret are returned. +
+ `entity.type` (Required) + + String + + The entity type. For secrets, this is always `secret`. +
+ `member.id` (Optional) + + String + + Filter grants by the ID of a specific user, group, system identity, or system identity group. +
+ `member.type` (Optional) + + Enum + + The type of member to filter by. Valid values: `USER`, `GROUP`, `SYSTEM_IDENTITY`, `SYSTEM_IDENTITY_GROUP`. +
+ +#### Sample query: + +```graphql +{ + customerAdministration { + entityGrants( + filter: { + iamParent: { + id: { eq: "12345" } + scope: { eq: ACCOUNT } + } + entity: { + id: { eq: "production::account-12345::prod-api-key" } + type: { eq: "secret" } + } + } + cursor: "" + ) { + items { + targetEntity { + id + } + member { + memberId + memberType + } + id + role { + name + id + } + } + nextCursor + } + } +} +``` + +### Response + + + + + + + + + + + + + + + + + + +
+ **Attribute name** + + **Description** +
+ `items` + + An array of grant objects, each containing: + * `targetEntity.id`: The entity ID of the secret + * `member.memberId`: The ID of the user, group, system identity, or system identity group + * `member.memberType`: The type of member (USER, GROUP, SYSTEM_IDENTITY, or SYSTEM_IDENTITY_GROUP) + * `id`: The unique identifier of the grant (use this to revoke access) + * `role.name`: The name of the role granted + * `role.id`: The unique identifier of the role +
+ `nextCursor` + + The cursor value for pagination. Use this value in the next query to retrieve additional results. +
+ +#### Sample response: + +```json +{ + "data": { + "customerAdministration": { + "entityGrants": { + "items": [ + { + "targetEntity": { + "id": "production::account-12345::prod-api-key" + }, + "member": { + "memberId": "system-identity-id-abc123", + "memberType": "SYSTEM_IDENTITY" + }, + "id": "grant-id-xyz789", + "role": { + "name": "Secret Reader", + "id": "role-id-for-secret-reader" + } + } + ], + "nextCursor": null + } + } + } +} +``` + +
+ +
+ +## Related topics [#related-topics] + + + + Get started with New Relic's GraphQL API + + + Use the NerdGraph API explorer to test queries and mutations + + + Create and manage user groups with custom roles + + + Use secrets in infrastructure agent configuration + +