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