On Thu, 8 Sep 2016 at 17:11 Alex Heneveld <alex.henev...@cloudsoftcorp.com> wrote:
> > HTTPS > > This has also been mentioned and while I would like it in an ideal > world, the scare-the-daylights splash screen that browsers show if you > have a self-signed cert is a compelling reason in my mind to adopt the > same philosophy, start easy and document security, rather than start > secure but hard-to-use. > We might want to look at let's encrypt for this (https://letsencrypt.org/) works pretty well and seems rather simple to setup (which was the all point of this project) > > > --A > > > > On 08/09/2016 16:58, Aled Sage wrote: > > Hi Alex, > > > > Good points. > > > > Are you strongly against the status quo as well (given that the > > password may be "buried" when installing on a server)? > > > > --- > > It feels like your objections are mostly about the auto-generated > > password, rather than about whether we have unauthenticating localhost. > > > > Do you think we should change the behavior so that it sets up an > > initial default well-known credential of admin:password (which we log > > and document), and have localhost login require the same authentication? > > > > (I'd be hesitant about that, given the server may be publicly > > reachable and is opening an easily guessable password on a predictable > > port.) > > > > However, that would give consistency for all ways of launching > > Brooklyn. There are several use-cases to consider: > > > > * Vagrant (we already auto-populate brooklyn.properties with > > admin:password, I believe). > > * Install on a server > > o using RPM/DEB > > o manually running karaf (with `./bin/start`) > > o manually running `./bin/brooklyn launch` > > * Install on localhost (using any of the three ways listed above) > > > > --- > > I was hoping to separate the work into two parts: making localhost and > > server behaviour consistent; and proper user/credential management. > > > > Longer term, options include: > > > > * Installing the rpm/deb doesn't start the service (giving the user a > > chance to configure security first) > > * Force the user to change the initial password on first login, etc. > > > > Aled > > > > > > On 08/09/2016 16:09, Alex Heneveld wrote: > >> > >> Aled- > >> > >> I'm strongly against this. Nearly all OSS software puts a priority > >> of making it easy to get started, at the expense of pre-configured > >> password (karaf's admin:admin) or no auth (most nosql datastores). > >> The good OSS software then describes clearly what's needed to make it > >> secure. I think we do a pretty good job of both. > >> > >> I'd welcome any install process tweak which encourages setting a > >> password in an easy way (and this would help vagrant) But I think > >> it's unacceptable for the default to be a password buried in a log > >> file ... or anything which makes it significantly harder to get started. > >> > >> (And do people really evaluate software on a shared server, in this > >> day and age???) > >> > >> Best > >> Alex > >> > >> > >> > >> On 08/09/2016 15:42, Aled Sage wrote: > >>> I'd expect a lot of folk evaluating Brooklyn for real use-cases to > >>> install Brooklyn on a server, rather than their laptop owned by > >>> their employer. Or for them to use Vagrant. > >>> > >>> For Vagrant, we can auto-populate it with an initial > >>> username:password in the brooklyn.properties file. > >>> > >>> And for Brooklyn on a server, I think we should taking security > >>> seriously so not allow unauthenticated access from any user who does > >>> a curl command from that server! > >>> > >>> Aled > >>> > >>> > >>> On 08/09/2016 15:35, Aled Sage wrote: > >>>> Hi Mike, > >>>> > >>>> That touches on a bigger piece of work: to look at the runtime > >>>> management of user logins (e.g. if using HA, how are the user > >>>> credentials shared with the other HA servers; where do we write to > >>>> for changes in credentials; etc). > >>>> > >>>> We don't support changing user passwords on-the-fly (one has to > >>>> modify the brooklyn.properties file, and then trigger a reload via > >>>> the rest api or ui). > >>>> > >>>> Currently, for production use-cases we'd recommend use of something > >>>> like LDAP for that. We don't want to re-implement a lot of what > >>>> LDAP does, but we do want a reasonable out-of-the-box experience. > >>>> > >>>> Aled > >>>> > >>>> > >>>> On 08/09/2016 15:15, Mike Zaccardo wrote: > >>>>> +0. My hesitation is the con of more difficult first user > >>>>> experience. > >>>>> Could a compromise be that localhost login works unauthenticated > >>>>> the first > >>>>> time but immediately prompts the user to set a username and password? > >>>>> > >>>>> On Thu, Sep 8, 2016 at 10:12 AM Aled Sage <aled.s...@gmail.com> > >>>>> wrote: > >>>>> > >>>>>> Hi all, > >>>>>> > >>>>>> I'd like to remove from Brooklyn the feature where you can login > >>>>>> authenticated from localhost. > >>>>>> _* > >>>>>> Current Situation*_ > >>>>>> When you first start Brooklyn on a new machine (so no > >>>>>> brooklyn.properties etc), it will auto-generate an initial > >>>>>> username + > >>>>>> password and log that. For example: > >>>>>> > >>>>>> 2016-09-08 15:03:48,631 INFO No security provider options > >>>>>> specified. Define a security provider or users to prevent a > >>>>>> random > >>>>>> password being created and logged. > >>>>>> 2016-09-08 15:03:48,632 INFO Starting Brooklyn web-console > >>>>>> with > >>>>>> passwordless access on localhost and protected access from > >>>>>> any other > >>>>>> interfaces (no bind address specified) > >>>>>> 2016-09-08 15:03:48,633 INFO Allowing access to web console > >>>>>> from > >>>>>> localhost or with brooklyn:sgZZL9qqBd > >>>>>> 2016-09-08 15:03:50,572 INFO Started Brooklyn console at > >>>>>> http://127.0.0.1:8083/, running classpath://brooklyn.war@ > >>>>>> > >>>>>> If you connect from localhost, you can login without any > >>>>>> credentials. > >>>>>> > >>>>>> If you connect from an external IP, you will need to use those > >>>>>> credentials. > >>>>>> > >>>>>> _*Pros and Cons*_ > >>>>>> This is convenient for first-time users (they don't need to worry > >>>>>> about > >>>>>> setting up a username/password if running Brooklyn on their local > >>>>>> machine). We have to explain a little less before they can try > >>>>>> out AMP. > >>>>>> > >>>>>> But it will also feel like a security hole. > >>>>>> > >>>>>> It will makes the experience of installing Brooklyn on a server very > >>>>>> different from the localhost experience. This is particularly > >>>>>> true as we > >>>>>> encourage the use of RPM/DEB for installing Brooklyn. > >>>>>> > >>>>>> _*Proposal*_ > >>>>>> I propose removing this, so localhost logins also require > >>>>>> credentials. > >>>>>> > >>>>>> We'd also ensure the docs point at the username:password for > >>>>>> accessing > >>>>>> the web-console. It is a problem that we don't already call this out > >>>>>> (e.g. at > >>>>>> > >>>>>> > http://brooklyn.apache.org/v/latest/start/running.html#control-apache-brooklyn > >>>>>> > >>>>>> and http://brooklyn.apache.org/v/latest/ops/gui/running.html) > >>>>>> because > >>>>>> users installing on a server will not know what to do. > >>>>>> > >>>>>> Aled > >>>>>> > >>>>>> > >>>> > >>> > >> > > > > > > -- Thomas Bouron • Software Engineer @ Cloudsoft Corporation • http://www.cloudsoftcorp.com/ Github: https://github.com/tbouron Twitter: https://twitter.com/eltibouron
