Re: Internal key management system
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Craig Ringer <craig.ringer@enterprisedb.com>
Cc: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>, Fabien COELHO <coelho@cri.ensmp.fr>, Cary Huang <cary.huang@highgo.ca>, Ahsan Hadi <ahsan.hadi@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, "Moon, Insung" <tsukiwamoon.pgsql@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Sehrope Sarkuni <sehrope@jackdb.com>, cary huang <hcary328@gmail.com>, Ibrar Ahmed <ibrar.ahmad@gmail.com>, Joe Conway <mail@joeconway.com>
Date: 2020-10-27T11:15:25Z
Lists: pgsql-hackers
On Mon, Oct 26, 2020 at 10:05:10PM +0800, Craig Ringer wrote: > For example if I want to lock my database with a YubiHSM I would configure > something like: > > cluster_encryption_key = 'pkcs11:token=YubiHSM;id=0:0001;type=private' Well, openssl uses a prefix before the password string, e.g.: * pass:password * env:var * file:pathname * fd:number * stdin See 'man openssl'. I always thought that API was ugly, but I now see the value in it. We could implement a 'command:' prefix now, and maybe a 'pass:' one, and allow other methods like 'pkcs11' later. I can also imagine using the 'file' one to allow the key to be placed on an encrypted file system that has to be mounted for Postgres to start. You could also have the key on a USB device that has to be inserted to be used, and the 'file' is on the USB key --- seems clearer than having to create a script to 'cat' the file. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee