On Tue, Mar 14, 2017 at 12:32:10PM -0700, Russ Allbery wrote: > "Henry B (Hank) Hotz, CISSP" <hbh...@oxy.edu> writes: > > Shut down all daemons on the master. > > > hprop --decrypt --stdout | hpropd --stdin > > > Restart all daemons. > > You probably also want to shut down incremental propagation while you do > this. I think this should force a full resync when the slaves reconnect, > but it would be a good idea to thoroughly test the replication behavior in > a test realm before doing this in a production realm. I forget how it > deals with a complete database reload; I think it's supposed to do > something sane, but that would be the component that I would worry about.
Good point, but actually restarting the daemons does not force a full resync. You have to remove the iprop log file (on the master and/or the slaves -- either works) to force a full resync. > Note that you will need to manually copy the new master key to the slaves > before they'll be able to replicate. Also don't forget to keep the old > master key around for the length of your backup retention so that you > don't invalidate your backups. If you're not storing the master key on a different disk anyways, and maybe even if you are, I would recommend just not encrypting the HDB at all. As with MIT, only the principals' keys are encrypted, which leaves you subject to cut-n-paste attacks by, e.g., your backups operator. You should separately encrypt the backups/dumps. Even if we could put the master key in a hardware token, that would not be sufficient to make the keys that much more secure. The only case that KDB/HDB encryption gets you more security is where it's easier to steal the disks than the whole system, and you either store the master key on a disk that's inside the system or you type it in when the daemons start. With modern kit that's just not the case, so you might as well not encrypt the KDB/HDB. (MIT doesn't give you the option; Heimdal does.) Nico --
