All Products
Search
Document Center

PolarDB:Use PolarDB Always-confidential

Last Updated:Aug 27, 2026

High-privilege roles, such as database administrators (DBAs) and developers, may access sensitive data like user identity information and transaction records when maintaining databases. This creates a risk of data leaks. The PolarDB for MySQL PolarDB Always-confidential feature encrypts query results on the fly at the database proxy layer. This ensures that only authorized applications that use a specific driver can decrypt and access sensitive data. You can use this feature to secure sensitive data and meet compliance requirements with minimal changes to your application code.

How it works

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

  • Data storage: This feature does not change the physical storage state of data in the database. The data remains in plaintext in operating system (OS) files and on disks.

  • User perspectives:

    • Super Admin: Query results are always returned in plaintext and are unaffected by encryption policies. This facilitates database management.

    • Standard Account: Query results are returned as ciphertext. A specific encryption driver, such as the EncJDBC driver or the GoLang driver, and the correct key are required to decrypt the data on the client.

    • other users: Query results are returned as ciphertext and cannot be decrypted, even with the key.

Prerequisites

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

Note
  • View the version number: You can view the current database proxy version of your cluster on the Settings and Management > Version Control 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, we recommend that you 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 left-side navigation pane, click Clusters, select the region where your cluster is located, and then click the cluster ID to go to the cluster details page.

  2. In the left-side navigation pane, choose Settings and Management > Security, and then click the Encrypt tab.

Step 1: Configure keys

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

KMS key (Recommended)

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

Note

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

Configure a Customer Master Key (CMK)

  1. Purchase and enable a KMS instance.

  2. Create a Customer Master Key (CMK).

  3. Return to the PolarDB console, select the corresponding CMK, and click OK.

Self-managed key

If you do not configure KMS, the system uses a self-managed key by default. You are responsible for generating, distributing, and storing the key.

Important

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

Step 2: Define role permissions

On the Encrypt page, go to the Role Policy Settings tab to configure roles for different database accounts. This determines whether they see plaintext or ciphertext when they query data.

  1. Click Create Role Permission Policy.

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

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

    2. Super Account: 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 Account role has the highest permissions. Add only necessary management or audit accounts to this list and strictly control their use.

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

    Note

    other users: Any database account not configured in the preceding two roles. These users receive query results as ciphertext and cannot decrypt the data.

Step 3: Create an encryption policy

On the Encrypt page, go to the Encryption Policy Settings tab to 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 explicitly specify the database, table, and field names. Avoid using configurations that apply to all databases or all tables to prevent affecting unrelated services.

    Parameter

    Description

    Rule Name

    Required. The unique identifier for the policy, for example, encrypt-user-email. The length cannot exceed 64 characters.

    Description

    Optional. A detailed description of the policy, such as Encrypt the email field in the user table of the customer database. The length cannot exceed 64 characters.

    Enable/Disable Rule

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

    Associate 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: This setting applies only to the specified databases. Use a comma , to separate multiple database names.

    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: Applies only to the specified tables. Separate multiple table names with a comma ,.

    Column Name

    Required. The names of the fields to encrypt, separated by a comma ,.

    Encryption Algorithm

    Required. The algorithm to use for encryption. This feature supports the following algorithms:

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

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

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

  3. Click OK to create the policy.

Step 4: Manage encryption policies

On the Encrypt page, go to the Encryption Policy Settings tab to manage existing policies.

  • 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.

Security hardening

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

Core principle

Create separate RAM users for relevant personnel, grant them permissions to manage PolarDB, but explicitly deny them the permissions to modify or delete encryption policies.

Instructions

  1. Create a deny policy

    1. Log on to the RAM console. In the left-side navigation pane, choose Permissions > Policies. Click Create Policy to create a custom policy.

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

      • Effect: Deny.

      • Service: PolarDB.

      • Actions: Select Specify Actions. Under Write operations, select polardb:ModifyMaskingRules and polardb:DeleteMaskingRules.

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

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

  2. Configure RAM user permissions

    1. Log on to the RAM console. In the left-side navigation pane, choose Identities > Users. Find the target RAM user and click Add Permissions in the Actions column.

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

Result

If a restricted RAM user attempts to modify or delete an encryption policy, the console displays a No Permission error. The error indicates that the current operation is explicitly denied, with the error code Forbidden.RAM and the authorization action polardb:ModifyMaskingRules. The policy type is an identity-based policy (account-level), and the permission decision is an explicit deny. The user must contact the account administrator for authorization.

Next steps

After you configure the encryption rules, your application must use an encryption-capable driver, such as the EncJDBC driver or the GoLang driver, to correctly read and write encrypted data.

FAQ

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

Check the account used to log on to the database. If the account is configured as a Super Account, query results are always in plaintext for ease of management. To see the ciphertext results, test with an account configured as a Standard Account.

How can I verify that encryption is working?

Use a database account that is not in the Super Account list to connect to the database by using a standard MySQL client, such as the command line or Navicat. Then, query the encrypted field. If you see ciphertext, the query results are being encrypted on the fly at the database proxy layer.

What are the risks of the Super Admin role?

The Super Account role can directly read plaintext data, completely bypassing encryption protection. We recommend that you use this role only temporarily for absolutely necessary scenarios, such as data correction, migration, or auditing. Remove the account from this role immediately after use and maintain a complete audit trail of all operations.