brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John McCabe <j...@johnmccabe.net>
Subject Re: [PROPOSAL] Remove unauthenticated localhost login
Date Thu, 08 Sep 2016 19:18:49 GMT
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 <john@johnmccabe.net> 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 <
> geoff.macartney@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.heneveld@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.sage@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
>> >>>>>>>
>> >>>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >>
>> >
>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message