Implement access method enforcement via the GUC variable

Description

Currently the users can change the default access method by changing the database template which will not affect existing, but new databases and new tables.

This could be overwritten. To make this change resistant to users changing (overwriting) it, we would have to create an event trigger that would raise an issue for users who try to create a table with an access method that is not encrypted.

So the design would be:

  1. Add a new GUC pg_tde.force_encrypted_access, default value false

    An event trigger checks pg_tde.force_encrypted_access during table creation or altering the table access method. If the value is set true and the target access method is not encrypted, the operation fails with an error message.

  2. During or after installation the value would have to be changed to true

    pg_tde.force_encrypted_access can be set at system level, overridden at database level and again at user level. It can only be set by a superuser and does not require a restart. The setting is not checked for operations by superusers, so is effectively false for them.

    <aside> 🧪

    For testing purposes the user setting overrides the database, the database setting overrides the system

    </aside>

For instance, in a multi-tenant environment, users of a single database are forced to create encrypted tables, except for one non-superuser who is allowed to create unencrypted tables.

  • False (or not set) at system level.

  • True at database level

  • False for the user allowed to create unencrypted tables

SUCCESS CRITERIA:

Acceptance Criteria

DBA can ensure that databases use TDE access method and it cannot be changed

How to document

None

How to test

None

Activity

Show:
Done

Details

Assignee

Reporter

Labels

Sprint

Fix versions

Priority

Smart Checklist

Created January 23, 2025 at 10:33 AM
Updated March 3, 2025 at 2:02 PM
Resolved February 5, 2025 at 7:20 PM