All Products
Search
Document Center

PolarDB:Use PolarDB Always-confidential

Last Updated:Apr 16, 2026

High-privilege roles, such as database administrators (DBAs) and developers, can expose sensitive data like user identity information or transaction records while maintaining production databases. The PolarDB Always-confidential feature for PolarDB for MySQL mitigates this risk by encrypting query results on the fly at the database proxy layer. This ensures that only authorized applications using a specific driver can decrypt and view sensitive data. With minimal changes to your application code, this feature helps you protect sensitive data and meet compliance requirements.

How it works

The PolarDB Always-confidential feature operates at the database proxy layer. When an SQL query matches a configured encryption policy, the proxy encrypts the data in the 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 Admin: Query results are always returned as plaintext. Encryption policies do not affect these accounts, simplifying database management.

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

    • Other users: Query results are returned as ciphertext and cannot be decrypted, even if the key is available.

Prerequisites

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

Note
  • View the version number: View the 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 policies is merged with the dynamic data masking feature. To improve the user experience and manage features independently, we recommend upgrading the proxy to version 2.9.12 or later.

Configure on-the-fly encryption

Configuring on-the-fly encryption involves three main steps: configure a key, define role-based permissions, and create an encryption policy.

Procedure

  1. Log on to the PolarDB console. In the left-side navigation pane, click Clusters. Select the region where your cluster is deployed and click the cluster ID.

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

Step 1: Configure a key

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

Use a KMS key (recommended)

Alibaba Cloud Key Management Service (KMS) hosts your keys, supports automatic key rotation, and provides a high level of security and maintainability. If an AccessKey pair used to access KMS is compromised, you can mitigate the risk by disabling the AccessKey pair or restricting the access policy. The key itself is not exposed.

Note

Only the customer master key (CMK) type from KMS is supported. The default key type is not supported. For more information, see Overview of Key Management Service.

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 appropriate CMK, and click OK.

Use a 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 compromised, and key rotation is not 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 Role Policy Settings tab of the Encrypt page, configure roles for different database accounts. This configuration determines whether users see plaintext or ciphertext when querying data.

  1. Click Create Role Permission Policy.

  2. In the Role Permission Settings dialog box, specify the 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 checkboxes of the database accounts that you want to assign to this role. You can select multiple accounts. Database accounts in this list always receive query results as plaintext.

      Note

      The Super Account role has the highest level of permissions. Grant this role only to essential management or audit accounts and strictly control its use.

    3. Standard Account: Select the checkboxes of the database accounts that you want to assign to this role. You can select multiple accounts. Database accounts in this list receive query results as ciphertext but can decrypt the data using a specific encryption driver and the correct key.

    Note

    Other users: Any database account not assigned to the Super Admin or Standard Account role receives query results as ciphertext and cannot decrypt the data.

image

Step 3: Create and enable an encryption policy

On the Encryption Policy Settings tab of the Encrypt page, 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 all tables to avoid inadvertently affecting other 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.

    Description

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

    Enable/Disable Rule

    Controls policy activation. Policies are enabled by default and cannot be disabled during creation. You can change this setting later from the policy list.

    Associate Permission Policy

    Required. Select the role permission policy you defined in Step 2.

    Database

    Optional. The database to which the policy applies. The following options are available:

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

    • Specify databases: Applies the policy only to the specified databases. Separate multiple database names with commas (,).

    Table Name

    Optional. The table to which the policy applies. The following options are available:

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

    • Specify tables: Applies the policy only to the specified tables. Separate multiple table names with commas (,).

    Column 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 to create the policy.

Step 4: Manage encryption policies

On the Encryption Policy Settings tab of the Encrypt page, you can manage the policies that you created in the policy list.

  • Modify a policy: Find the policy that you want to modify and click Modify in the Actions column.

  • Delete a policy: Find the policy that you want to delete, click Delete in the Actions column, and then click OK in the confirmation dialog box.

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

Security hardening with fine-grained permissions

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

Core concept

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

Procedure

  1. Create a policy to deny modification

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

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

      • Effect: Deny.

      • Service: PolarDB.

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

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

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

  2. Assign permissions to a RAM user

    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 click OK.

Result

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

Next steps

After configuring encryption policies, your application must use an encryption-capable driver, such as the JDBC driver (EncJDBC) 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 database account you used to log on. If the account is assigned the Super Account role, query results are always in plaintext to simplify management. To view ciphertext, use an account assigned the Standard Account role.

How can I verify that encryption is enabled?

Use a database account that is not in the Super Account list to connect to the database from a standard MySQL client, such as the command line or Navicat. Then, query an encrypted field. A ciphertext result proves that on-the-fly encryption is working at the database proxy layer.

What are the risks associated with the Super Admin role?

The Super Account role can read plaintext data directly, bypassing encryption. We recommend that you use this role only for essential tasks, such as data correction, migration, or auditing. After completing the tasks, immediately remove the account from this role and ensure that a complete audit trail of all operations is maintained.