Key Management Service (KMS) lets you share a single KMS instance with multiple member accounts in your organization. Instead of each team or department provisioning its own KMS instance, a central account owns one instance and grants access to others — reducing costs and consolidating security policy in one place.
How it works
Cross-account sharing relies on two Alibaba Cloud services: Resource Directory (for organization management) and Resource Sharing (for access delegation).
The workflow involves three phases:
Set up an organization. Use Resource Directory to group all relevant Alibaba Cloud accounts under a single organization.
Share the KMS instance. The resource owner creates a resource share, adds the KMS instance, and specifies which members (principals) can access it.
Grant permissions. Two permission layers apply:
Resource Sharing layer: The resource owner attaches
AliyunRSDefaultPermissionKMSInstanceto the resource share. This grants principals the ability to connect to the KMS instance.RAM layer: Each principal must configure a resource access management (RAM) policy for its RAM users or roles to allow specific KMS API calls, such as
kms:Encryptandkms:Decrypt.
Example: Department A owns a KMS instance. Department B needs key management capabilities. Instead of purchasing a separate instance, the enterprise uses Resource Directory to unify both accounts under one organization, then shares Department A's KMS instance with Department B through Resource Sharing.
Prerequisites
Before you begin, make sure that you have:
An enabled software key management instance or hardware key management instance (disabled instances cannot be shared)
A management account for the Resource Directory
The instance owner and all principals belong to the same verified enterprise and the same Resource Directory
Choose a sharing mode
KMS instance sharing supports two modes that differ in how data ownership is handled:
| Independent ownership | Joint ownership | |
|---|---|---|
| Use cases | Cross-account secrets with the same name, or strict permission isolation between accounts | Central team (such as IT or security) manages and audits all keys and secrets across accounts |
| Data ownership | The resource owner cannot manage or access keys and secrets created by principals | The resource owner can manage and access keys and secrets created by principals |
| Same-name resources | Allowed — the principal and the resource owner can create secrets with the same name | Not allowed — all key and secret names within the instance must be unique |
| Mode change | Cannot be changed to joint ownership | Can be changed to independent ownership (irreversible) |
For the full permission breakdown by role, see Appendix: Feature permissions in different sharing modes.
Configure sharing (instance owner)
Step 1: Set up Resource Directory and enable resource sharing
Set up Resource Directory:
Log on to the Resource Management console using the management account.
In the left navigation pane, go to Resource Directory > Enable Resource Directory, then click Enable Resource Directory. For details, see Enable a resource directory.
Create a folder to group members: go to Resource Directory > Management, click Resource Organization View in the upper-right corner, select the target folder in the directory tree, and on the Member tab, click Create Folder. Enter a Folder Name and click OK. For details, see Create a folder.
Add members to the folder: on the Member tab, click Create Member or Invite Member. Configure the following parameters:
Invite members
Parameter Description Account ID or logon email address Enter an account ID or the logon email used to register the account. Separate multiple account IDs with commas to invite in batches. To find an account ID, see How do I view the ID of an Alibaba Cloud account? Remarks A remark to help the invitee verify the invitation's authenticity. Tag Tags to bind to the member for easier management. Parent folder The folder to place the invited account in. Defaults to the root folder. Click Modify to change. Create a member
Parameter Description Alibaba Cloud account name Unique identifier for the member within the resource directory. Must be 2–50 characters and can contain letters, numbers, and _.-. Must start and end with a letter or number, and cannot contain consecutive special characters.Display name 2–50 characters; supports Chinese characters, letters, digits, and _.-.Billing account Choose who pays for the new member's fees: the management account, an existing member, or the new member itself. Tag Tags to bind to the member for easier management. Parent folder Defaults to the root folder. Click Modify to change.
Enable resource sharing:
Log on to the Resource Sharing console using the management account. In the left navigation pane, go to Resource Sharing > Settings.
Click Enable, then click OK in the Resource Sharing Service-Linked Role dialog box.
The system automatically creates a service-linked role named
AliyunServiceRoleForResourceSharingto retrieve organization information from Resource Directory. For details, see Service-linked role for Resource Sharing.
Step 2: Share the KMS instance
Log on to the Key Management Service console as the instance owner. Select a region in the top menu bar, then click Instances in the left navigation pane.
Find the target KMS instance and click Share Resources in the Actions column. In the RD Multi-account Sharing Settings panel, select a sharing mode.
In the Add to Resource Share panel, choose how to configure the resource share:
WarningAdding a KMS instance to an existing resource share grants all current principals of that share automatic access to the new instance. This consumes the instance's Access Management Quota and may cause unintended permission escalation. Proceed with caution.
Create (recommended) Select an existing resource share Use when Sharing for the first time, or when you need permission isolation per instance Adding the current instance to an existing share to reuse its principals and permissions Permission scope Only the current KMS instance; only newly added accounts gain access All existing principals automatically gain access to the new instance; permission changes affect all resources in the share Configure the resource share parameters and click OK:
If creating a new resource share:
Resource share name — Up to 50 characters; supports Chinese characters, letters, digits, and
._-.Principals — Specify which accounts can use this KMS instance. Each principal added consumes the instance’s Access Management Quota. Adding or removing principals from an existing resource share affects all resources within that share. Three principal types are supported:
Principal type Scope Alibaba Cloud Account Shares resources with specified account IDs only Resource Directory Organization Shares resources with all member accounts in the entire resource directory, including members added later Folder (organizational unit) Shares resources with all members in the specified folder (format: fd-xxxxxxxx), including members added later. To find folder IDs, see View the basic information of a folder.Add principals by folder or Alibaba Cloud Account for fine-grained control.
Permissions — Select
AliyunRSDefaultPermissionKMSInstance(recommended). Two versions are available (v1 and v2); new shares default to v2. To verify the version in use, see View permission details. The permissionAliyunRSPermissionKMSInstanceReadWriteis deprecated and not recommended for new shares.
If selecting an existing resource share:
Select resource share — The console lists all resource shares in your account. See Create a resource share for reference.
Shared resources — Read-only. Shows the existing resources in the selected share. After this operation, the current KMS instance is added.
Principals and Permissions — Same options as when creating a new share. Note:
AliyunRSPermissionKMSInstanceReadWriteis deprecated; if previously used, continue using it only for that share.
Use the shared instance (principal)
Log on to the Key Management Service console. On the Instances page, find the KMS instance with a Being Shared tag to confirm the share is active.
Create keys and secrets on the Keys or Secrets tab. Select the shared instance for KMS Instance. For configuration details, see Create a key and Create a secret.
Grant RAM users or roles the permissions they need. Configure a RAM policy that includes the relevant KMS operations, such as
kms:Encryptandkms:Decrypt. For instructions, see Use RAM for access control.Use the keys and secrets in other Alibaba Cloud services or your own applications:
Server-side encryption for cloud products: Overview of KMS integration for cloud products and Cloud products that support KMS integration
Integrate secrets with cloud services: Integrate cloud products with KMS secrets
Self-managed applications: Self-built application integration with KMS
Manage and maintain the share
Modify the principals of a resource share
From the KMS console:
Log on to the Key Management Service console as the instance owner. Select a region, then click Instances in the left navigation pane.
On the Instances page, open the Software Key Management or Hardware Key Management tab based on the instance type.
Find the instance and click Share Resources in the Actions column.
In the RD Multi-account Share Settings panel, select a Resource Share. In the Principals section, click Edit to add or remove principals, then click OK.
From the Resource Sharing console:
For detailed instructions, see Modify a resource share.
Revoke sharing for a KMS instance
Revoking a share means deleting the resource share. After deletion, all principals lose access to the resources in that share.
Before revoking a share, each principal must delete all keys and secrets they created in the shared instance. If any resources remain, the revocation fails. Confirm that no associated resources are still in use to avoid business disruptions.
Perform this operation from the Resource Sharing console only:
Log on to the Resource Sharing console using a management account.
In the left navigation pane, go to Resource Sharing > Resources I Share. Find the target resource share and click its ID.
Click Delete Resource Share in the upper-right corner. In the confirmation dialog box, click OK.
Apply in production
Network connectivity
If a principal's application runs in a VPC and needs to access KMS through a private gateway, the instance owner must attach the principal's VPC to the shared KMS instance. For instructions, see Access a KMS instance from multiple VPCs in the same region.
Audit and compliance
Resource owner: Enable ActionTrail to record all management operations on the shared instance and all key operations performed by principals.
Principal: Enable ActionTrail to record all API calls within your account.
Change management
Revoking sharing: Before revoking a share, principals must delete all keys and secrets they created in the shared instance. If resources remain, the revocation fails. For instructions, see Revoke sharing for a KMS instance.
Modifying principals: Adding or removing principals from a resource share affects all resources within that share. Create separate resource shares for different business scenarios or teams to avoid permission conflicts. For instructions, see Modify the principals of a resource share.
Limitations
Default keys (such as
alias/acs/oss) cannot be shared.Principals cannot access a shared KMS instance across regions.
In Joint Ownership mode, all key and secret names within the instance must be globally unique.
Access Management Quota: Sharing a KMS instance consumes the resource owner's Access Management Quota. The used quota equals the number of shared accounts plus the number of attached VPCs. For example, sharing with 3 accounts and attaching 2 VPCs consumes a quota of 5. If you need to increase your quota, upgrade the KMS instance.
ImportantIf adding a principal fails due to insufficient quota, the system does not automatically retry after you increase the quota. Manually remove the principal from the resource share, then add it again.
FAQ
Why does a principal receive an "AccessDenied" or "Forbidden" error when calling a KMS API?
Check the following four conditions in order:
Resource sharing status: In the Resource Sharing console, confirm the principal's account is added to the resource share and the sharing status is active.
KMS instance permission: Verify that the permission attached to the resource share is
AliyunRSDefaultPermissionKMSInstance.RAM call permission: Confirm that the RAM user or role making the call has a RAM policy that grants the required KMS operations, such as
kms:Encryptandkms:Decrypt.Resource ownership: In Independent Ownership mode, confirm that the current principal created the key or secret being accessed.
Why do I get a name conflict error when creating a secret in joint ownership mode?
In joint ownership mode, all key and secret names within the KMS instance must be unique across all accounts. Neither the resource owner nor any principal can create a resource with a name already in use.
To resolve this: choose a different name, or switch the sharing mode to Independent Ownership if your use case requires same-name resources across accounts.
Switching from joint ownership to independent ownership is irreversible. Evaluate the impact before proceeding.
Appendix: Feature permissions in different sharing modes
Joint ownership
| Feature | Sub-feature | Instance owner | Principal |
|---|---|---|---|
| Instance management | View KMS instance details | Supported | Not supported |
| Configure multi-VPC access to KMS instances | Supported | Not supported | |
| Upgrade instances | Supported | Not supported | |
| Renew instances | Supported | Not supported | |
| Revoke sharing | Supported | Not supported | |
| Key management | Create keys | Supported | Supported |
| View key metadata | Supported — applies to all keys, including those created by principals | Supported — applies only to keys created by the principal | |
| Set key rotation | Supported | Supported | |
| Schedule key deletion | Supported | Supported | |
| Enable deletion protection | Supported | Supported | |
| Create and manage key aliases | Supported | Supported | |
| Add and manage key tags | Supported | Supported | |
| Cryptographic operations | — | Supported | Not applicable |
| Secret management | Create secrets | Supported | Supported |
| View secret metadata | Supported — applies to all secrets, including those created by principals | Supported — applies only to secrets created by the principal | |
| Delete secrets | Supported | Supported | |
| Set secret rotation | Supported | Supported | |
| Add and manage secret tags | Supported | Supported | |
| Get secret value | Not applicable | Supported | |
| Backup management | — | Supported — can back up all keys and secrets, including those created by principals | Not supported |
| Application access | Create application access points | Supported | Supported |
Independent ownership
| Feature | Sub-feature | Instance owner | Principal |
|---|---|---|---|
| Instance management | View KMS instance details | Supported | Not supported |
| Configure multi-VPC access for KMS instances | Supported | Not supported | |
| Upgrade instances | Supported | Not supported | |
| Renew instances | Supported | Not supported | |
| Revoke sharing | Supported | Not supported | |
| Key management | Create keys | Supported | Supported |
| View key metadata | Supported — applies only to keys created by the instance owner | Supported — applies only to keys created by the principal | |
| Set key rotation | Supported | Supported | |
| Schedule key deletion | Supported | Supported | |
| Enable deletion protection | Supported | Supported | |
| Create and manage key aliases | Supported | Supported | |
| Add and manage key tags | Supported | Supported | |
| Cryptographic operations | — | Supported | Not applicable |
| Secret management | Create secrets | Supported | Supported |
| View secret metadata | Supported — applies only to secrets created by the instance owner | Supported — applies only to secrets created by the principal | |
| Delete secrets | Supported | Supported | |
| Set secret rotation | Supported | Supported | |
| Add and manage secret tags | Supported | Supported | |
| Get secret value | Not applicable | Supported | |
| Backup management | — | Supported — applies only to keys created by the instance owner | Not supported |
| Application access | Create application access points | Supported | Supported |