Depending on circumstances, I'd work on physical security for the master (perhaps putting the master in a separate locked cabinet), and then login security for it as well - implement 2FA, such as a proximity card or other assurance.
Any idea what the threat model is? Kurt On Tue, Apr 15, 2014 at 4:11 AM, Andrew S. Baker <[email protected]> wrote: > Correct... In addition to using certificate-based logons, rather than > password-based logons. > > > > > > > *ASB **http://XeeMe.com/AndrewBaker* <http://xeeme.com/AndrewBaker> > *Providing Virtual CIO Services (IT Operations & Information Security) for > the SMB market…* > > > > > On Mon, Apr 14, 2014 at 6:31 PM, Kurt Buff <[email protected]> wrote: > >> Aside from using public keys vs. passwords? >> >> Kurt >> >> >> On Mon, Apr 14, 2014 at 9:14 AM, Andrew S. Baker <[email protected]>wrote: >> >>> Good afternoon: >>> >>> I have an interesting question about secure configuration between puppet >>> orchestration master servers and their minions. >>> >>> (for those who don't use puppet, you can look at it here: >>> http://puppetlabs.com/puppet/puppet-enterprise ) >>> >>> The question pertains to using SSH to secure the communication between >>> the master server and its slave servers. What other mechanisms would you >>> consider to ensure that this SSH connection does not get abused? (As it >>> would essentially be always active) >>> >>> Regards, >>> >>> >>> >>> >>> >>> >>> *ASB **http://XeeMe.com/AndrewBaker* <http://xeeme.com/AndrewBaker> >>> *Providing Virtual CIO Services (IT Operations & Information Security) >>> for the SMB market…* >>> >>> >>> >> >
