[
https://issues.apache.org/jira/browse/COUCHDB-2390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14215394#comment-14215394
]
Javier Candeira commented on COUCHDB-2390:
------------------------------------------
Ah, [~kxepal], good points all. So both [admins] and _authdb need to be
rethought in the presence of each other, and the behaviour has to be thought
for the following operations:
- new cluster spun up from zero
- cluster spun up from backups, both _authdb and config/[admins]
- new node added to existing cluster
And my first-blush answer to your questions, with the caveat that I haven't
thought about it too much, and this is more of a Thinking Out Loud...
When a new node is added to a cluster, the node/cluster admins will have to be
synchronised in some form. This is irrespecitve of whether admins are
maintained in an [admins] section in the config file, or in the _authdb
database.
We are eliminating admin party, so all nodes will have some admins. There are
two scenarios here:
1.- nodes have node admins which are different from cluster admins
2.- node admins have to be cluster admins too
I think the first scenario is too confusing, but let's keep it for a while. So
for a node to join a cluster, all admin users have to be shared between nodes,
with the same password. This can happen in two ways:
a.- nodes can join a cluster as long as they have one admin/password pair match
one of those of the cluster.
b.- nodes can only join in a cluster when all their admin/password match those
of the cluster
In the (a) model, the set of admin/password pairs for the whole cluster is the
intersection of the set of admin/password pairs for each one of the nodes. The
rest of admins (those not present in all nodes, or those present but with
diferring passwords) are disabled as admins.
1a means that nodes can have admin users for the node that are not admin users
for the cluster. Can be confusing for the user.
1b is impossible by the rules.
2a means that as soon as a node joins a cluster, some of the node admins are
disabled. How would that be communicated?
2b is technically the easiest, as it requires out-of-band synchronisation of
admin/password pairs by administrative means.
TL; DR:
Since the erlang secret has to be the same in all nodes in a DB before they can
even talk to each other, you might as well drop an identical [admins] section
in the config of any node in a cluster at the same time as you write the erlang
secret. So my vote is still that
- we use model 2b "all user/password pairs shared between nodes in a cluster".
Note that this is something that is independent of using [admins] or _authdb as
an authority for admin user/passwords.
- an error is raised when a node wants to join a cluster without the correct
set of admin/password pairs.
- node/cluster admins are sychronised administratively, out of band,
- user/password sharing between nodes is done by writing an equivalent [admins]
section in the config file in all relevant nodes.
> Fauxton config, admin sections considered dangerous in 2.0
> ----------------------------------------------------------
>
> Key: COUCHDB-2390
> URL: https://issues.apache.org/jira/browse/COUCHDB-2390
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: BigCouch, Fauxton
> Reporter: Joan Touzet
> Priority: Blocker
>
> In Fauxton today, there is are 2 sections to edit config-file settings and to
> create new admins. Neither of these sections will work as intended in a
> clustered setup.
> Any Fauxton session will necessarily be speaking to a single machine. The
> config APIs and admin user info as exposed will only add that information to
> a single node's .ini file.
> We should hide these features in Fauxton for now (short-term fix) and correct
> the config /admin creation APIs to work correctly in a clustered setup
> (medium-term fix).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
