Gerrit init with ldap

[Darragh Bailey]

Hi,

Currently in the process of automating the stand up and configuration of a Gerrit insurance with ldap and noticed a few bumps around the initial admin account and use of said account for subsequent additional service account creation.

Have tried to configure Gerrit to come up connected to ldap initially, using a dedicated application account but run into some problems:

* internal application ldap accounts must use a password containing special characters, while do not work with basic authentication as required for the rest api.

* Gerrit doesn't seem to support cookie based access to the rest api's so even though I can auth with curl and save the cookie to use for the next operations, it isn't accepted

* internal application ldap accounts do not have sufficient information to populate certain fields such as the ssh username which means I can't trigger a HTTP password generation

It feels like there should be a programmable way to establish an initial account during the initialisation even if using ldap or oath authentication that can then be used configure any additional service account and groups.

Right now it looks like we'll bring Gerrit up in development_become_any_account mode listening to localhost only, then create some addition service/management accounts (at least one for admin access) followed by reconfiguring Gerrit to use ldap and forcing a restart.

Is there any better solutions in this area?

--

Darragh Bailey
"Nothing is foolproof to a sufficiently talented fool" - unknown

[Jan Kundrát]

On čtvrtek 16. února 2017 21:22:41 CET, Darragh Bailey wrote:
> * internal application ldap accounts must use a password containing special
> characters, while do not work with basic authentication as required for the
> rest api.
> * Gerrit doesn't seem to support cookie based access to the rest api's so
> even though I can auth with curl and save the cookie to use for the next
> operations, it isn't accepted
> * internal application ldap accounts do not have sufficient information to
> populate certain fields such as the ssh username which means I can't
> trigger a HTTP password generation

It seems that #3 is your problem. Are the features in [1] not enough?

When this is solved, you can then use the Gerrit-generated HTTP password
for authenticating against the REST API.

> It feels like there should be a programmable way to establish an initial
> account during the initialisation even if using ldap or oath authentication
> that can then be used configure any additional service account and groups.

The first account which logs in through the web interface becomes an
administrator. On Gerrit systems that I bootstrapped, this was usually
enough (even though I'm a big fan of automatization).

> Right now it looks like we'll bring Gerrit up in
> development_become_any_account mode listening to localhost only, then
> create some addition service/management accounts (at least one for admin
> access) followed by reconfiguring Gerrit to use ldap and forcing a restart.

This is no better than just letting your first user become an
administrator.

Cheers,
Jan

[1]
https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#ldap.accountS

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

[Darragh Bailey]

On 17 February 2017 at 07:29, Jan Kundrát <j...@flaska.net> wrote:

On čtvrtek 16. února 2017 21:22:41 CET, Darragh Bailey wrote:

* internal application ldap accounts must use a password containing special
characters, while do not work with basic authentication as required for the
rest api.

David Borowitz suggested in the IRC room that this may not be my problem. AFAIK base64 encoding is only guaranteed to be consistently decoded  for iso-8859-1, however it may be that problem 3 below is what is causing this to fail.

Looking at the gerrit logs when attempting to use the application account for the REST API:
"Authentication failed for test-gerrit: account inactive or not provisioned in Gerrit"

 

* Gerrit doesn't seem to support cookie based access to the rest api's so
even though I can auth with curl and save the cookie to use for the next
operations, it isn't accepted
* internal application ldap accounts do not have sufficient information to
populate certain fields such as the ssh username which means I can't
trigger a HTTP password generation

It seems that #3 is your problem. Are the features in [1] not enough?

When this is solved, you can then use the Gerrit-generated HTTP password for authenticating against the REST API.

Unfortunately not, if there was a way to have a fallback field, then could work around this.

The standard user accounts have a field for their unix ssh username, but application accounts don't have the same field, and the ldap.accountSshUsername doesn't appear to allow for an either/or possibility.

 

It feels like there should be a programmable way to establish an initial
account during the initialisation even if using ldap or oath authentication
that can then be used configure any additional service account and groups.

The first account which logs in through the web interface becomes an administrator. On Gerrit systems that I bootstrapped, this was usually enough (even though I'm a big fan of automatization).

We looking to test changes to the entire CICD pipeline before deploying the change, so need to be able to spin up and bootstrap the environment from the previous stage and then apply updates, followed by automatically verifying that most functionality hasn't been broken.

We can do this with auth set to DEVELOPMENT_BECOME_ANY_ACCOUNT, but also need to do it with a test ldap account to make sure that things work correctly when attached to LDAP.

So needing to wait someone to login is not an option.

Right now it looks like we'll bring Gerrit up in
development_become_any_account mode listening to localhost only, then
create some addition service/management accounts (at least one for admin
access) followed by reconfiguring Gerrit to use ldap and forcing a restart.

This is no better than just letting your first user become an administrator.

It appears that after switching to LDAP the original development admin account becomes inaccessible, so we can use that to create the first few local service accounts, and since the system was brought up in development_become_any_account and admin was accessed, it seems to prevent the first ldap user from being promoted to admin after the switch.

This allows us to create another admin account with unique name/password that is specific to the environment (dev/staging/production) and then use that to create service accounts for jeepyb (which we use to manage all subsequent ACLs) and zuul (listens to the event stream).

 

Cheers,
Jan

[1] https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#ldap.accountS

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

--
--
To unsubscribe, email repo-discuss+unsubscribe@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

--- You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Darragh Bailey]

On Friday, February 17, 2017 at 10:27:20 AM UTC, Darragh Bailey wrote:

On 17 February 2017 at 07:29, Jan Kundrát wrote:

On čtvrtek 16. února 2017 21:22:41 CET, Darragh Bailey wrote: 

Right now it looks like we'll bring Gerrit up in
development_become_any_account mode listening to localhost only, then
create some addition service/management accounts (at least one for admin
access) followed by reconfiguring Gerrit to use ldap and forcing a restart.

This is no better than just letting your first user become an administrator.

It appears that after switching to LDAP the original development admin account becomes inaccessible, so we can use that to create the first few local service accounts, and since the system was brought up in development_become_any_account and admin was accessed, it seems to prevent the first ldap user from being promoted to admin after the switch.

This allows us to create another admin account with unique name/password that is specific to the environment (dev/staging/production) and then use that to create service accounts for jeepyb (which we use to manage all subsequent ACLs) and zuul (listens to the event stream).

So it turns out this works reasonably well for our use case.

Really the driving requirement here is that we want a configuration management controlled account to be the main administrator account, to manage the credentials used and then subsequently to be want creates any additional local service accounts that are required.

I'm sure some environments it is possible to have service accounts in the backing auth created in a way that the needed fields are present to be able to authenticate that account using the REST api, but I'm also sure there are a number of environments that this is not feasible as well, and we're just one such case.
 

--

Darragh Bailey
"Nothing is foolproof to a sufficiently talented fool"

Looking at the source code for creating the default admin account when using DEVELOPMENT_BECOME_ANY_ACCOUNT, it seems like the basis for supporting create a local admin automatically for any auth on first initialization only is all there.

Would a change to allow for such an account to be created for all auth systems, automatically for DEVELOPMENT_BECOME_ANY_ACCOUNT and only on explicit request for all others, be accepted if it was coded up?

[Edwin Kempin]

Sure.