re: letsencrypt, their flow requires the node requesting the cert be publicly accessible, a problem for getting started, but super useful in most other cases.
On Thu, 8 Sep 2016 at 20:17 John McCabe <[email protected]> wrote: > -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 < > [email protected]> 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 <[email protected]> >> 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 <[email protected]> >> 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 >> >>>>>>> >> >>>>>>> >> >>>>> >> >>>> >> >>> >> >> >> >> >> > >> >>
