Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Поиск
Список
Период
Сортировка
От Antonin Houska
Тема Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)
Дата
Msg-id 3439.1560777912@localhost
обсуждение исходный текст
Ответ на Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)  (Masahiko Sawada <sawada.mshk@gmail.com>)
Ответы Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)  (Antonin Houska <ah@cybertec.at>)
Список pgsql-hackers
Masahiko Sawada <sawada.mshk@gmail.com> wrote:

> The cluster-wide TDE eventually encrypts SLRU data and all WAL
> including non-user data related WAL while table/tablespace TDE doesn't
> unless we develop such functionality. In addition, the cluster-wide
> TDE also encrypts system catalogs but in table/tablespace TDE user
> would be able to control that somewhat. That is, if we developed the
> cluster-wide TDE first, when we develop table/tablespace TDE on top of
> that we would need to change TDE so that table/tablespace TDE can
> encrypt even non-user data related data while retaining its simple
> user interface, which would rather make the feature complex, I'm
> concerned.

Isn't this only a problem of pg_upgrade? If the whole instance (including
catalog) is encrypted and user wants to adopt the table/tablespace TDE, then
pg_upgrade can simply decrypt the catalog, plus tables/tablespaces which
should no longer be encrypted. Conversely, if only some tables/tablespaces are
encrypted and user wants to encrypt the whole cluster, pg_upgrade will encrypt
the non-encrypted files.

> We can support them as different TDE features but I'm not sure it's a good
> choice for users.

IMO it does not matter which approach (cluster vs table/tablespace) is
implemented first. What matters is to design the user interface so that
addition of the other of the two features does not make users confused.

-- 
Antonin Houska
Web: https://www.cybertec-postgresql.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Obsolete comments about semaphores in proc.c
Следующее
От: Antonin Houska
Дата:
Сообщение: Re: pg_log_fatal vs pg_log_error