Ihar, thanks for pointing that out - I'll definitely take a close look. Jon, I'm not very familiar with Barbican, but I did assume the full implementation would use Barbican to store private keys. However, in terms of actually getting a private key (or SSH host cert) into a VM instance, Barbican doesn't help. The instance needs permission to access secrets stored in Barbican. The main question of my e-mail is: how do you inject a credential in an automated but secure way? I'd love to hear ideas - in the meantime I'll study Ihar's link.
thanks, Pino On Fri, Sep 29, 2017 at 2:49 PM, Ihar Hrachyshka <[email protected]> wrote: > What you describe (at least the use case) seems to resemble > https://review.openstack.org/#/c/456394/ This work never moved > anywhere since the spec was posted though. You may want to revive the > discussion in scope of the spec. > > Ihar > > On Fri, Sep 29, 2017 at 12:21 PM, Giuseppe de Candia > <[email protected]> wrote: > > Hi Folks, > > > > > > > > My intent in this e-mail is to solicit advice for how to inject SSH host > > certificates into VM instances, with minimal or no burden on users. > > > > > > > > Background (skip if you're already familiar with SSH certificates): > without > > host certificates, when clients ssh to a host for the first time (or > after > > the host has been re-installed), they have to hope that there's no man in > > the middle and that the public key being presented actually belongs to > the > > host they're trying to reach. The host's public key is stored in the > > client's known_hosts file. SSH host certicates eliminate the possibility > of > > Man-in-the-Middle attack: a Certificate Authority public key is > distributed > > to clients (and written to their known_hosts file with a special syntax > and > > options); the host public key is signed by the CA, generating an SSH > > certificate that contains the hostname and validity period (among other > > things). When negotiating the ssh connection, the host presents its SSH > host > > certificate and the client verifies that it was signed by the CA. > > > > > > > > How to support SSH host certificates in OpenStack? > > > > > > > > First, let's consider doing it by hand, instance by instance. The only > > solution I can think of is to VNC to the instance, copy the public key > to my > > CA server, sign it, and then write the certificate back into the host > (again > > via VNC). I cannot ssh without risking a MITM attack. What about using > Nova > > user-data? User-data is exposed via the metadata service. Metadata is > > queried via http (reply transmitted in the clear, susceptible to > snooping), > > and any compute node can query for any instance's meta-data/user-data. > > > > > > > > At this point I have to admit I'm ignorant of details of cloud-init. I > know > > cloud-init allows specifying SSH private keys (both for users and for SSH > > service). I have not yet studied how such information is securely > injected > > into an instance. I assume it should only be made available via > ConfigDrive > > rather than metadata-service (again, that service transmits in the > clear). > > > > > > > > What about providing SSH host certificates as a service in OpenStack? > Let's > > keep out of scope issues around choosing and storing the CA keys, but > the CA > > key is per project. What design supports setting up the SSH host > certificate > > automatically for every VM instance? > > > > > > > > I have looked at Vendor Data and I don't see a way to use that, mainly > > because 1) it doesn't take parameters, so you can't pass the public key > out; > > and 2) it's queried over http, not https. > > > > > > > > Just as a feasibility argument, one solution would be to modify Nova > compute > > instance boot code. Nova compute can securely query a CA service asking > for > > a triplet (private key, public key, SSH certificate) for the specific > > hostname. It can then inject the triplet using ConfigDrive. I believe > this > > securely gets the private key into the instance. > > > > > > > > I cannot figure out how to get the equivalent functionality without > > modifying Nova compute and the boot process. Every solution I can think > of > > risks either exposing the private key or vulnerability to a MITM attack > > during the signing process. > > > > > > > > Your help is appreciated. > > > > > > > > --Pino > > > > > > ____________________________________________________________ > ______________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: [email protected]?subject: > unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
