All Products
Search
Document Center

PolarDB:Use the Confidential Database feature

Last Updated:Jan 14, 2026

High-privilege roles, such as database administrators (DBAs) and developers, can access sensitive data, such as user identities and transaction records, in a production environment during database maintenance. This poses a data breach threat. The PolarDB for MySQL Confidential database feature encrypts query results in real time at the database proxy layer. This ensures that only authorized applications that use a specific driver can decrypt and access sensitive data. This feature lets you protect sensitive data and meet compliance requirements with only minor changes to your application code.

How it works

The Confidential database feature works at the database proxy layer. When an SQL query matches a configured encryption policy, the proxy layer encrypts the data in specified fields before returning the query results to the client.

  • Data storage: This feature does not change how data is physically stored in the database. The data remains in plaintext in operating system (OS) files and on cloud disks.

  • User perspectives:

    • Super administrator: Query results are always in plaintext and are not affected by encryption policies. This facilitates database management.

    • Regular user: Query results are returned as ciphertext. Regular users must use specific encryption drivers, such as the EncJDBC driver and the GoLang driver, and the correct key to decrypt the data on the client.

    • Other users: Query results are in ciphertext and cannot be decrypted, even with the key.

Scope

The database proxy version of your PolarDB for MySQL cluster must be 2.9.12 or later.

Note
  • View the version number: You can view the database proxy version of your cluster on the Settings and Management > Version Management page.

  • Version compatibility: If the database proxy version is earlier than 2.9.12 but later than 2.8.18, the configuration interface for encryption rules is merged with the dynamic data masking feature. For the best experience and feature independence, upgrade to version 2.9.12 or later.

Configure on-the-fly encryption

Configuring on-the-fly encryption involves three main steps: configuring a key, defining role permissions, and creating an encryption policy.

Procedure

  1. Go to the PolarDB console. In the navigation pane on the left, click Clusters. Select the region where your cluster is located, and then click the ID of the target cluster to open the cluster details page.

  2. In the navigation pane on the left, click Settings and Management > Security, and then click the Encryption tab.

Step 1: Configure a key

On the Encryption page, turn on the Key Management switch to configure a key for application-side encryption and decryption.

Use a KMS key (Recommended)

Alibaba Cloud Key Management Service (KMS) lets you host your keys, supports key rotation (automatic key updates), and provides a high level of security and maintainability. Even if an AccessKey (AK) used to access KMS is leaked, you can control the risk by disabling the AK or strengthening the access policy. The key itself is not compromised.

Note

Only the Customer Master Key type in KMS is supported. The Default Key is not supported. For more information, see Key Service Overview.

Configure a KMS customer master key

  1. Purchase and enable a KMS instance.

  2. Create a customer master key (CMK).

  3. Return to the PolarDB console, select the corresponding customer master key, and click OK.

Use a self-managed key

If you do not configure KMS, the system uses a self-managed key by default. You must generate, distribute, and store the key yourself.

Important

Self-managed keys are at risk of being lost or leaked, and key updates are not currently supported. If a key is lost, the corresponding encrypted data cannot be decrypted. You must establish strict security procedures to manage your keys.

Step 2: Define role permissions

On the Encryption page, on the Customer Role Permission Settings tab, you can configure roles for different database accounts. This determines whether an account can view data in plaintext or only in ciphertext when querying data.

  1. Click Create Role Permission Policy.

  2. In the Role Permission Settings dialog box, set the policy name and the database accounts for the roles.

    1. Policy Name: Specify a name for the policy. The name can be up to 64 characters long.

    2. Super administrator: Select the check boxes of the database accounts. You can select multiple accounts. Database accounts in this list always receive query results in plaintext.

      Note

      The Super administrator role has the highest permissions. Add only necessary management or audit accounts to this list and strictly control their use.

    3. Regular user: Select the check boxes of the database accounts. You can select multiple accounts. Database accounts in this list receive query results in ciphertext but can decrypt the data using a specific encryption driver and key.

    Note

    Other users: This role includes any database account not specified in the super administrator or regular user roles. These users receive query results in ciphertext and cannot decrypt the data.

image

Step 3: Create and enable an encryption policy

On the Encryption page, on the Encryption Policy Settings tab, configure an encryption policy.

  1. Click Create Encryption Policy.

  2. In the dialog box that appears, configure the policy parameters as described in the following table.

    Note

    Specify a precise encryption scope: When you create a policy, always specify the database, table, and field names. Avoid applying the policy to all databases or tables to prevent it from affecting unrelated services.

    Parameter

    Description

    Rule Name

    Required. A unique identifier for the policy, such as encrypt-user-email. The name can be up to 64 characters long.

    Rule Description

    Optional. A detailed description of the policy, such as Encrypt the email field in the user table of the customer database. The description can be up to 64 characters long.

    Enable/Disable Rule

    A switch to enable or disable the policy. The policy is enabled by default when created and cannot be changed during creation. You can modify this setting after the policy is created.

    Associated Permission Policy

    Required. Select the role permissions defined in Step 2.

    Database

    Optional. The database to which the policy applies. You can select one of the following options:

    • (Default) All databases: The policy applies to all databases in the cluster.

    • Specify databases: The policy applies only to the specified databases. Separate multiple database names with a comma ,.

    Table Name

    Optional. The table to which the policy applies. You can select one of the following options:

    • (Default) All tables: The policy applies to all tables in the specified database.

    • Specify tables: The policy applies only to the specified tables. Separate multiple table names with a comma ,.

    Field Name

    Required. The names of the fields to encrypt. Separate multiple field names with commas (,).

    Encryption Algorithm

    Required. The algorithm to use for encryption. The following algorithms are supported:

    • SM4 series: SM4-128-CBC, SM4-128-ECB, SM4-128-GCM, SM4-128-GTR.

    • AES-128 series: AES-128-CBC, AES-128-ECB, AES-128-GCM, AES-128-GTR.

    • AES-256 series: AES-256-CBC, AES-256-ECB, AES-256-GCM, AES-256-GTR.

  3. Click OK.

Step 4: Manage encryption policies

On the Encryption page, on the Encryption Policy Settings tab, you can manage your existing policies in the policy list.

  • Modify a policy: Find the target rule and click Modify in the Actions column.

  • Delete a policy: Find the target rule, click Delete in the Actions column, and then click OK in the dialog box that appears.

  • Enable or disable a policy: Find the target rule and click the switch in the Enable/Disable Rule column.

Permission convergence and security hardening

To prevent DBAs or developers with console permissions from maliciously modifying or deleting encryption policies, you can use Resource Access Management (RAM) for security hardening.

Core concept

Create separate Resource Access Management (RAM) users for relevant personnel, grant them permissions to manage PolarDB, and explicitly deny them permissions to modify or delete encryption policies.

Instructions

  1. Create a policy to deny modifications

    1. Log on to the Resource Access Management (RAM) console. In the navigation pane on the left, choose Permission Management > Access Policies, and then click Create Policy.

    2. On the visual editor tab, configure the following parameters:

      • Effect: Deny.

      • Service: PolarDB.

      • Action: Select Specify Action. In the Write section, select polardb:ModifyMaskingRules and polardb:DeleteMaskingRules.

      • Resource and Condition: Specify the objects to which the policy applies and the conditions under which the policy takes effect. For more information, see Basic elements of an access policy.

      • After the configuration is complete, click OK. In the Create Policy dialog box, set the Policy Name and Note.

  2. Configure RAM user permissions

    1. Log on to the Resource Access Management (RAM) console. In the navigation pane on the left, choose Identity Management > Users. Find the target RAM user and click Add Permissions in the Actions column.

    2. In the Access Policies section, select the deny policy that you created, and click OK.

Result

When the restricted RAM user tries to modify or delete an encryption policy, an error message indicating insufficient permissions is displayed.image

What to do next

After you configure the encryption rules, your application must use the JDBC driver (EncJDBC) or the GoLang driver, which have built-in decryption capabilities, to correctly read and write encrypted data.

FAQ

I configured an encryption policy. Why do I still see plaintext when I query data using a database client?

Check the account that you used to log on to the database. If the account is configured as a super administrator, query results are always returned in plaintext to facilitate management. To view the ciphertext results, test the query using an account that is configured as a regular user.

How can I verify that encryption is working?

Use a database account that is not on the super administrator list to connect to the database using a standard MySQL client, such as the command line or Navicat. Then, query the encrypted field. If you see ciphertext, this verifies that the query results are being encrypted in real time at the database proxy layer.

What are the risks of the super administrator role?

The super administrator role can directly read plaintext data, completely bypassing encryption protection. This role should be used only temporarily for necessary scenarios, such as data correction, migration, or auditing. Remove the account from this role immediately after the task is complete and maintain a complete audit trail of all operations.