By way of comparison, Jenkins deploys out of the box with no auth. On Thu, 8 Sep 2016 at 21:11 Svetoslav Neykov < [email protected]> wrote:
> Letsencrypt (or any other certification) is a no go on localhost or on > remotes where you don't know the domain name used to access it. > Browsers are moving slowly to a place where even plain http will trigger > security warnings so self-signed won't be such a bad alternative at that > point. > > +1 for removing unauthenticated localhost access > > >> 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. > > Here's an alternative which has a better user experience with the same > level of security. > When Brooklyn starts it sees that no password is configured so generates > one (as it does currently) and puts it in brooklyn.properties or > etc/brooklyn.cfg (btw straightforward to implement in Karaf). The > documentation points the user to look for the password in that file which > is very easy to do as the file is minimally populated at this point - way > easier than sorting through a log file - always at the same line. This has > the possitive effect that the password remains the same between restarts. > It's been discussed already - don't remember what the cons were? > > >Is there a way to pass metadata to rpm/deb? That would be nice, we > recommend running "yum install brooklyn -d admin.password=s3cr3t" > That's no different from telling the user in docs to do "yum install > brooklyn && echo admin.password=s3cr3t >> /etc/brooklyn.cfg". The former > feels like magic, the latter self-documents how to change the password at > any point. > As for the question itself - won't be surprised if passing an environment > variable will let the postinstall script access it and do whatever it needs > to (as a subshell to the current session). > > > Svet. > > > > On 8.09.2016 г., at 22:18, John McCabe <[email protected]> wrote: > > > > 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 > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>> > >>> > >
