mongodb admin password no longer admin-secret on trunk

[Kapil Thangavelu]

moving to the api, means the lazy password change on the db is no longer operational. instead only the random password generated by machine-0 is valid for the admin account which is only stored afaics in machine-0/agent.conf as 'oldpassword'. This is a regression for applications that need to talk to mongodb, and were using the client-side jenv admin-secret as the password.

[John A Meinel (jameinel)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2014-01-21 18:25, Curtis Hovey wrote:
> ** Changed in: juju-core Status: New => Triaged
>
> ** Changed in: juju-core Importance: Undecided => High
>
> ** Changed in: juju-core Milestone: None => 1.17.1
>
> ** Tags added: api regression
>
> ** Tags added: security
>

I do believe it is intended that:

1) The admin-secret will become the actual password on Mongo

*but*

2) We will remove direct access to the MongoDB port outside of the
local network. (In 1.20, once the Juju CLI no longer uses it in 1.18.)

If you have specific needs for it to be exposed, we should get those
outlined, because we currently consider it a security vulnerability
that we expose MongoDB directly.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLfi+AACgkQJdeBCYSNAANMPACgzEyJRmY+KwVV/pOpboks7FY1
5RMAoMmykbfpHtgwJ5gV0j32LB6GTn9a
=oLjo
-----END PGP SIGNATURE-----

[William Reade (fwereade)]

This also breaks juju restore.

[John A Meinel (jameinel)]

The plan is to remove the admin user and block the mongodb port from the outside. We won't be implementing that in 1.18 (because we still want to support 1.16 clients).
So unless there is a strong use case for exposing mongodb again, we really don't want to, so we don't plan on spending time fixing this.

[Kapil Thangavelu (hazmat)]

i think this could use some discussion, juju as a magic black box, would be helpful to have some introspection or debugging capabilities, and sans core providing those, the database is it. the fact that its stored in old-password is bit indicative that this is a code bug, cause the code doesn't even know what the password is and just blindly tries a few till it works. ie its breaking internal assumptions as well.

[John A Meinel (jameinel)]

It is by design, actually. It was done as a security check. We wanted
a secret token, but didn't want to write it to the metadata service.
So instead we generate the random token, and then take the hash of it
as the initial password and write the hash of it to the metadata
service for cloud-init.
We then waited for the instance to start, connect with
password=hash(password) and then would set it to the real password
(preventing anyone who could sneak a peek at the cloud metadata from
having direct DB access).

However, a better security fix is to *just not let anyone access the
DB* :). Now that we have synchronous bootstrap, we don't have to put
agent passwords into the metadata because we do the setup directly
after ssh'ing into the machine we started.

On Wed, Mar 5, 2014 at 11:59 AM, Kapil Thangavelu
<email address hidden> wrote:
> i think this could use some discussion, juju as a magic black box,
> would be helpful to have some introspection or debugging capabilities,
> and sans core providing those, the database is it. the fact that its
> stored in old-password is bit indicative that this is a code bug, cause
> the code doesn't even know what the password is and just blindly tries a
> few till it works. ie its breaking internal assumptions as well.
>
> ** Changed in: juju-core
> Status: Won't Fix => Opinion
>
> --
> You received this bug notification because you are subscribed to juju-
> core.
> https://bugs.launchpad.net/bugs/1270434
>
> Title:
> mongodb admin password no longer admin-secret on trunk
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-core/+bug/1270434/+subscriptions