brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Macartney <geoff.macart...@cloudsoftcorp.com>
Subject Re: [PROPOSAL] Remove unauthenticated localhost login
Date Tue, 13 Sep 2016 15:25:24 GMT
hi Aled, 

Have been mulling this over since this debate started, and I actually like your ‘Alternative
Proposal 2’ - out-of-the-box there is no authentication.

That would be a super-easy experience for first-time users. For admins installing a production
machine, they’ll always expect to have to do some step to configure their own credentials,
so we document how to do that (and make it easy to do).

As John said, by way of comparison, Jenkins takes this approach.

This seems to me to be simpler and clearer than the first proposal.

Just my two cents.

Geoff


————————————————————
Gnu PGP key - http://is.gd/TTTTuI


> On 13 Sep 2016, at 15:32, Aled Sage <aled.sage@gmail.com> wrote:
> 
> Hi all,
> 
> I still think we really need to change the status quo. For me, there are two very compelling
arguments:
> 
> 1. In karaf, it will always prompt for a username and password.
>   If running in localhost, you can enter any text and it will accept
>   it. But you do have to "log in".
> 2. If running on a server, you need to find the auto-generated
>   username:password from the log or from stdout.
> 
> (1) is a bad user experience - the user doesn't know what to type, and then it turns
out that it is a pointless login dialog! It happens because the login is controlled by the
jaas configuration, which then delegates to Brooklyn code for checking the given username
and password.
> 
> For (2), I'd expect a fair number of users to go down this route. Currently the Brooklyn
docs are not good at telling you how to find this username and password (partly because we
have entirely different login behaviour for localhost, vagrant and remote-server). We are
also all in agreement (I think) that it's a poor user experience.
> 
> ---
> I'd like a consistent way for us to handle initial login on both localhost and server
(and vagrant) - one that we are happy for users to experience, and for us to document well.
> 
> ---
> _*New Proposal*_
> 
> On initial connection via the web-console, it asks the server if there is any security
configuration options set. If there is not, the web-console immediately re-directs the user
to a page for creating the initial user:password. Once submitted, the username and hash of
the password are written to $KARAF_HOME/etc/brooklyn.cfg for subsequent use.
> 
> Over time, we'd further improve this to allow someone to set up the initial security
configuration via this page (e.g. giving LDAP details, etc).
> 
> _Implementation Considerations_
> Not sure of the details. It would be a bit fiddly, but hopefully not too hard.
> 
> The web-console would need to do some initial requests to find out if a new user needs
to be created. It would then redirect, POST the user-creation request, and automatically login
with the new credentials.
> 
> Server-side, we'd need some way for an unauthenticated user to submit the is-security-configured
request and the initial-login-user-creation request. If we continue to use the existing Karaf
jaas configuration, then the web-console could have submitted some garbage credentials so
we get into the Brooklyn code (perhaps with default entitlements ensuring that all other access
is forbidden); or we could have an unauthenticated REST endpoint that would handle its own
security checks - always rejecting requests if any security configuration exists (which sounds
scary).
> 
> We'd need to extend the Brooklyn REST api for login-user-creation.
> 
> For now, it would write to the $KARAF_HOME/etc/brooklyn.cfg file. Longer term, we could
store the security config in the Brooklyn persisted state.
> 
> We could also extend the Brooklyn CLI to support doing the initial-login-user-creation.
> 
> ---
> _*Alternative Proposal 1*_
> If consensus is that folk really love the default of localhost-has-no-authentication,
then we could look more into how to configure Karaf jaas so that it doesn't prompt for a login.
I personally haven't been involved in that, so not sure how feasible/hard it is.
> 
> ---
> _*Alternative Proposal 2*_
> We could make the default be unauthenticated (including disabling jaas in the default
config files).
> 
> Aled
> 
> 
> On 08/09/2016 22:05, John McCabe wrote:
>> By way of comparison, Jenkins deploys out of the box with no auth.
>> 
>> On Thu, 8 Sep 2016 at 21:11 Svetoslav Neykov <
>> svetoslav.neykov@cloudsoftcorp.com> 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 <john@johnmccabe.net> 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 <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