-1 on removing it unless it can be reproduced in some form for the getting started envs, the vagrant envs for example are local to the users system and don't need to be secured as they are *not* intended for use in a production capacity (perhaps worth adding a note pointing the user to the section on securing a deploy (users/ssl etc)). The getting started ask on the user should be absolutely minimal, even default passwords aren't great UX in this context.
Alternatively I've seen flows where on a fresh install/first startup you are prompted to create an admin account when first accessing the UI. I would personally prefer that to default passwords (which is just as insecure as no password, maybe even less so). ps. hello ::) On Thu, 8 Sep 2016 at 17:19 Geoff Macartney < geoff.macart...@cloudsoftcorp.com> wrote: > > > > Is there a way to pass metadata to rpm/deb? That would be nice, we > recommend running "yum install brooklyn -d admin.password=s3cr3t" > > as far as I understand that’s not possible. I think there are workarounds > but they go against the intent of RPM. > > > > > ———————————————————— > Gnu PGP key - http://is.gd/TTTTuI > > > > On 8 Sep 2016, at 17:11, Alex Heneveld <alex.henev...@cloudsoftcorp.com> > wrote: > > > > > > > Are you strongly against the status quo as well (given that the > password may be "buried" when installing on a server)? > > > > It has always been ugly but has struck me as the least ugly option. > > > > Is there a way to pass metadata to rpm/deb? That would be nice, we > recommend running "yum install brooklyn -d admin.password=s3cr3t" > > > > > > In general though I think this area of the product is good. > > > > > > > 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. > > > > > > --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 > >>>>>>> > >>>>>>> > >>>>> > >>>> > >>> > >> > >> > > > >
