> > 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 >>>>>>> >>>>>>> >>>>> >>>> >>> >> >> >
