Help Center/ System Permissions/ User Guide/ Identity Policy–based Authorization/ Security & Compliance/ Data Encryption Workshop (DEW)/ Cloud Secret Management Service (CSMS)
Updated on 2025-11-06 GMT+08:00
View PDF
Share

Cloud Secret Management Service (CSMS)

IAM provides system-defined identity policies to define typical cloud service permissions. You can also create custom identity policies using the actions supported by cloud services for more refined access control.

In addition to IAM, the Organizations service also provides Service Control Policies (SCPs) to set access control policies.

SCPs do not actually grant any permissions to an entity. They only set the permissions boundary for the entity. When SCPs are attached to an organizational unit (OU) or a member account, the SCPs do not directly grant permissions to that OU or member account. Instead, the SCPs only determine what permissions are available for that member account or those member accounts under that OU. The granted permissions can be applied only if they are allowed by the SCPs.

To learn more about how IAM is different from Organizations for access control, see How IAM Is Different from Organizations for Access Control?.

This section describes the elements used by IAM custom identity policies and Organizations SCPs. The elements include actions, resources, and conditions.

Actions

Actions are specific operations that are allowed or denied in an identity policy.

  • The Access Level column describes how the action is classified (List, Read, or Write). This classification helps you understand the level of access that an action grants when you use it in an identity policy.
  • The Resource Type column indicates whether the action supports resource-level permissions.
    • You can use a wildcard (*) to indicate all resource types. If this column is empty (-), the action does not support resource-level permissions and you must specify all resources ("*") in your identity policy statements.
    • If this column includes a resource type, you must specify the URN in the Resource element of your identity policy statements.
    • Required resources are marked with asterisks (*) in the table. If you specify a resource in a statement using this action, then it must be of this type.

    For details about the resource types defined by CSMS, see Resources.

  • The Condition Key column contains keys that you can specify in the Condition element of an identity policy statement.
    • If the Resource Type column has values for an action, the condition key takes effect only for the listed resource types.
    • If the Resource Type column is empty (-) for an action, the condition key takes effect for all resources that action supports.
    • If the Condition Key column is empty (-) for an action, the action does not support any condition keys.

    For details about the condition keys defined by CSMS, see Conditions.

  • The Alias column lists the policy actions that are configured in identity policies. With these actions, you can use APIs for policy-based authorization. For details, see Policies and Identity Policies.

The following table lists the actions that you can define in identity policy statements for CSMS.

Table 1 Actions supported by CSMS

Action

Description

Access Level

Resource Type (*: required)

Condition Key

Alias

csms:secret:create

Grants permission to create or recover a secret.

Write

secretName *

-

-

csms:secret:delete

Grants permission to delete a secret immediately.

Write

secretName *

-

csms:secret:update

Grants permission to update the metadata of a secret.

Write

secretName *

-

csms:secret:get

Grants permission to query or download the secret information.

Read

secretName *

-

csms:secret:list

Grants permission to query all the secrets created by the current user under the current project.

List

secretName *

g:EnterpriseProjectId

-

csms:secret:createVersion

Grants permission to create a secret version in a specified secret.

Write

secretName *
  • csms:secretVersion:create

csms:secret:getVersion

Grants permission to query information about a specified secret version and its plaintext secret value.

Read

secretName *
  • csms:secretVersion:get

csms:secret:listVersion

Grants permission to list the available versions of a secret.

List

secretName *
  • csms:secretVersion:list

csms:secret:createStage

Grants permission to create a secret version stage.

Write

secretName *
  • csms:secretStage:create

csms:secret:getStage

Grants permission to query version information about a specified secret version stage.

Read

secretName *
  • csms:secretStage:get

csms:secret:updateStage

Grants permission to update a secret version stage.

Write

secretName *
  • csms:secretStage:update

csms:secret:deleteStage

Grants permission to delete a specified secret version stage.

Write

secretName *
  • csms:secretStage:delete

csms::getSecretQuota

Grants permission to query the secret quota of a specified project.

Read

-

-
  • csms:secretQuota:get

csms:secret:scheduleDeletion

Grants permission to schedule the deletion of a secret.

Write

secretName *
  • csms:secret:deleteScheduled

csms:secret:restoreSecret

Grants permission to cancel the scheduled deletion of a secret.

Write

secretName *
  • csms:secret:deleteCancelled

csms:secret:rotate

Grants permission to start secret rotation.

Write

secretName *

-

csms:secret:getSecretsByTag

Grants permission to list secrets filtered by tags.

List

secretName *

-
  • csms:tag:getSecretByTag

csms:secret:batchCreateOrDeleteTags

Grants permission to batch add or remove secret tags.

Tagging

secretName *
  • csms:tag:batch

-

csms:secret:createTag

Grants permission to add tags to a secret.

Tagging

secretName *
  • csms:tag:create

-

csms:secret:deleteTag

Grants permission to remove tags from a secret.

Tagging

secretName *
  • csms:tag:delete

-

g:TagKeys

csms:secret:listTags

Grants permission to list secret tags.

List

secretName *
  • csms:tag:getBySecret

csms::listProjectTags

Grants permission to list the secret tags under a specified project.

List

-

-
  • csms:tag:getAll

csms:secret:updateVersion

Grants permission to update the validity period of a secret version.

Write

secretName *
  • csms:secretVersion:update

csms::createEvent

Grants permission to create a secret event.

Write

-

-
  • csms:event:create

csms::listEvents

Grants permission to list all secret event notifications created by the current user under the current project.

List

-

-
  • csms:event:list

csms::getEvent

Grants permission to query a specified secret event notification.

Read

-

-
  • csms:event:get

csms::updateEvent

Grants permission to update the metadata of a specified secret event notification.

Write

-

-
  • csms:event:update

csms::deleteEvent

Grants permission to immediately delete a specified secret event notification.

Write

-

-
  • csms:event:delete

csms::listNotificationRecords

Grants permission to list the records about triggered event notifications.

List

-

-
  • csms:event:listNotificationRecords

csms::listTasks

Grants permission to list the secret rotation tasks.

List

-

-
  • csms:task:list

Each API of CSMS usually supports one or more actions. Table 2 lists the supported actions and dependencies.

Table 2 Actions and dependencies supported by CSMS APIs

API

Action

Dependencies

POST /v1/{project_id}/secrets

csms:secret:create

kms:cmk:createDataKey

POST /v1/{project_id}/secrets/{secret_name}/backup

csms:secret:get
  • kms:cmk:createDataKey
  • kms:cmk:decryptDataKey
  • kms:cmk:list

POST /v1/{project_id}/secrets/restore

csms:secret:create

kms:cmk:decryptDataKey

DELETE /v1/{project_id}/secrets/{secret_name}

csms:secret:delete

-

PUT /v1/{project_id}/secrets/{secret_name}

csms:secret:update

-

GET /v1/{project_id}/secrets/{secret_name}

csms:secret:get

-

GET /v1/{project_id}/secrets

csms:secret:list

-

POST /v1/{project_id}/secrets/{secret_name}/versions

csms:secret:createVersion

kms:cmk:createDataKey

GET /v1/{project_id}/secrets/{secret_name}/versions/{version_id}

csms:secret:getVersion

kms:cmk:decryptDataKey

GET /v1/{project_id}/secrets/{secret_name}/versions

csms:secret:listVersion

-

-

csms:secret:createStage

-

GET /v1/{project_id}/secrets/{secret_name}/stages/{stage_name}

csms:secret:getStage

-

PUT /v1/{project_id}/secrets/{secret_name}/stages/{stage_name}

csms:secret:updateStage

-

DELETE /v1/{project_id}/secrets/{secret_name}/stages/{stage_name}

csms:secret:deleteStage

-

-

csms::getSecretQuota

-

POST /v1/{project_id}/secrets/{secret_name}/scheduled-deleted-tasks/create

csms:secret:scheduleDeletion

-

POST /v1/{project_id}/secrets/{secret_name}/scheduled-deleted-tasks/cancel

csms:secret:restoreSecret

-

POST /v1/{project_id}/secrets/{secret_name}/rotate

csms:secret:rotate
  • rds:password:update
  • kms:cmk:createGrant
  • kms:cmk:retireGrant

POST /v1/{project_id}/csms/{resource_instances}/action

csms:secret:getSecretsByTag

-

POST /v1/{project_id}/csms/{secret_id}/tags/action

csms:secret:batchCreateOrDeleteTags

-

POST /v1/{project_id}/csms/{secret_id}/tags

csms:secret:createTag

-

DELETE /v1/{project_id}/csms/{secret_id}/tags/{key}

csms:secret:deleteTag

-

GET /v1/{project_id}/csms/{secret_id}/tags

csms:secret:listTags

-

GET /v1/{project_id}/csms/tags

csms::listProjectTags

-

PUT /v1/{project_id}/secrets/{secret_name}/versions/{version_id}

csms:secret:updateVersion

-

POST /v1/{project_id}/csms/events

csms::createEvent

-

GET /v1/{project_id}/csms/events

csms::listEvents

-

GET /v1/{project_id}/csms/events/{event_name}

csms::getEvent

-

PUT /v1/{project_id}/csms/events/{event_name}

csms::updateEvent

-

DELETE /v1/{project_id}/csms/events/{event_name}

csms::deleteEvent

-

GET /v1/{project_id}/csms/notification-records

csms::listNotificationRecords

-

GET /v1/{project_id}/csms/tasks

csms::listTasks

-

Resources

A resource type indicates the resources that an identity policy applies to. If you specify a resource type for any action in Table 3, the resource URN must be specified in the identity policy statements using that action, and the identity policy applies only to resources of this type. If no resource type is specified, the Resource element is marked with an asterisk (*) and the identity policy applies to all resources. You can also set condition keys in an identity policy to define resource types.

The following table lists the resource types that you can define in identity policy statements for CSMS.

Table 3 Resource types supported by CSMS

Resource Type

URN

secretName

csms:<region>:<account-id>:secretName:<secret-name>

Conditions

Condition Key Overview

A Condition element lets you specify conditions for when an identity policy is in effect. It contains condition keys and operators.

  • The condition key that you specify can be a global condition key or a service-specific condition key.
    • Global condition keys (with the g: prefix) apply to all actions. Cloud services do not need to provide user identity information. Instead, the system automatically obtains such information and authenticates users. For details, see Global Condition Keys.
    • Service-specific condition keys (with the abbreviation of a service name plus a colon as the prefix, for example, csms) apply only to operations of the xx service. For details, see Table 4.
    • The number of values associated with a condition key in the request context of an API call makes the condition key single-valued or multivalued. Single-valued condition keys have at most one value in the request context of an API call. Multivalued condition keys can have multiple values in the request context of an API call. For example, a request can originate from at most one VPC endpoint, so g:SourceVpce is a single-valued condition key. You can tag resources and include multiple tag key-value pairs in a request, so g:TagKeys is a multivalued condition key.
  • A condition operator, condition key, and a condition value together constitute a complete condition statement. An identity policy can be applied only when its request conditions are met. For supported condition operators, see operators.

Service-specific condition keys supported by CSMS

The following table lists the condition keys that you can define in identity policies for CSMS. You can include these condition keys to specify conditions for when your identity policy is in effect.

Table 4 Service-specific condition keys supported by CSMS

Service-specific Condition Key

Type

Single-valued/Multivalued

Description

csms:Type

string

Single-valued

Filters access by secret type.

csms:KmsKeyId

string

Single-valued

Filters access by KMS key ID.

csms:VersionId

string

Single-valued

Filters access by secret version ID.

csms:VersionStage

string

Single-valued

Filters access by secret version stage.

csms:RecoveryWindowInDays

numeric

Single-valued

Filters access by scheduled deletion time.