API change: managing SSH keys in Juju

Jim Baker jim.baker at canonical.com
Wed Nov 30 22:42:00 UTC 2011


On 11/28/2011 08:47 AM, Gustavo Niemeyer wrote:
>> I would appreciate any comments on this proposed API change to Juju.
>
> Thanks Jim. Let's see..

Thanks for the feedback!
>
>
>>  1. Configure via cloud-init using `ssh_keys`, which itself is a
>>     dictionary that has this key to file correspondence::
> (...)
>>       addition, the ZK secret (admin password of ZK) is also stored
>>       in instance metadata. So it doesn't get any worse with this
>>       approach.
>
> cloud-init is not a good place to have private information, as you
> anticipated. The fact we have other private information there is no
> excuse to introduce an insecure mechanism that is precisely
> attempting to improve security.

Here's a reworked version that takes this concern into account:

Managing SSH keys for ZooKeeper instances
-----------------------------------------

Juju bootstrap will generate two sets of keys. The first set is stored
in the per-instance metadata. However, this has an issue that any
process on the machine can access this metadata, via
http://169.254.169.254/latest/user-data. Upon ssh availability of the
bootstrapped machine, the second set is then stored and the public
keys only are written to the juju control bucket. At this point, the
bootstrap command itself is complete.

This procedure is adapted from the cloud-sandbox script that's part of
Dustin Kirkland's bikeshed project (https://launchpad.net/bikeshed).

One aspect of this change is that the bootstrap subcommand will now
have to wait until it has installed the second set of keys.

Although this is a separate task, extending the responsibilities of
bootstrap can also be an opportunity to refactor the initialization
of the ZK instance, currently done by the juju-admin command; see
https://bugs.launchpad.net/juju/+bug/708175 One important aspect of
this to ensure that admin secret is no longer stored in the
per-instance metadata.

The bootstrap step will generate two sets of SSH host keys (RSA, DSA,
and ECDSA) for the ZooKeeper instance (machine 0), which are used as
follows:

  1. Store the public parts of the second set of ssh keys for the ZK
     instance in the juju control bucket in the `provider-state` file
     (YAML formatted), under the key `instance_ssh_keys`. This a dict,
     with the key being the instance id; its value is identical to the
     public cloud-init contents of `ssh_keys` for each instance.

     The need to carefully update this file to enable future support
     of managing an ensemble of more than one ZK instance is not
     impacted by this change.

  2. Configure via cloud-init using `ssh_keys`, which itself is a
     dictionary that has this key to file correspondence::

         {
            "rsa_private" : "/etc/ssh/ssh_host_rsa_key",
            "rsa_public"  : "/etc/ssh/ssh_host_rsa_key.pub",
            "dsa_private" : "/etc/ssh/ssh_host_dsa_key",
            "dsa_public"  : "/etc/ssh/ssh_host_dsa_key.pub",
            "ecdsa_private" : "/etc/ssh/ssh_host_ecdsa_key",
            "ecdsa_public"  : "/etc/ssh/ssh_host_ecdsa_key.pub"
         }

     This process enables bootstrap to assume control of the instance
     in a subsequent step.

  3. Upon ssh availability of the ZK instance, the `juju bootstrap`
     subcommand installs the second set of keys in the paths as above
     and completes.

All providers in the Python implementation use a common implementation
to lookup ZK instances (`juju.providers.common.findzookeepers`). We
just need to modify `find_zookeepers` to return the
`instance_ssh_keys`, as well as the ZK machines.

The connection phase then checks for the existence of a
per-environment `known_hosts` file
(`~/.juju/${environment}/known_hosts`), creating as necessary, and
adds as necessary entries for the public keys of the chosen ZK machine
to connect to. This process ensures that these keys can be readily
shared across admin machines. (The security of this key propagation is
of course dependent on the `admin-secret` value in
`~/.juju/environments.yaml`; sharing this secret is what it makes it
possible to administer a Juju environment.)

With that place, juju commands that need to connect with ZK will now
work as desired.


>
>
> William already had a better grip on that problem, but there was one
> gotcha on his approach that he understandably didn't think of which is
> the fact txaws itself is completely insecure to man-in-the-middle
> attacks (which is, again, what we're trying to solve) since it doesn't
> verify the SSL certificates. The first step towards introducing
> security against man-in-the-middle is to fix txaws.
I have asked William about this, but I'm not certain what element was
better in his approach. Could you clarify?

In terms of the txaws issue, this bug now has a merge proposal from
Thomas Herve:
https://code.launchpad.net/~therve/txaws/ssl-verify

- Jim

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/juju/attachments/20111130/113de830/attachment.pgp>


More information about the Juju mailing list