Concourse: Make local users cleanup as optional behavior.

Created on 21 Dec 2018  路  3Comments  路  Source: concourse/concourse

What challenge are you facing?

Since Concourse version 4.2, teams do not create anymore basic auth users.
To reproduce this kind of user in Concourse 4.2 we have to use local-user option.
Which create/sync password in the database. I worked on Concourse upgrade from 3.14.1 to 4.2.1.

During the upgrade to make my current setup work, I ensured that the basic auth users of all of our teams are present as local users: https://concourse-ci.org/install.html#local-auth-config

--add-local-user myuser:mypass

Looking on the current behavior, all those users have to be specified in clear username/password at Concourse startup params, so:

  1. If there is one missing in the command line, it will be deleted.
  2. If you don't specify the add-local-user command, all local users will be deleted.

Which could end up in accidental deletion of (all) user(s). It also forces you to have the clear list of those users/passwords on Concourse service startup script.

What would make this better?

As improvement proposal, we could give the choice to Concourse users to decide if they want or not this cleanup behavior. That would allow to safely connect Concourse to a database with local user already present.
This could be achieved in 2 ways:

  1. Add a flag to control the cleaup. skip-local-user-cleanup or local-user-cleanup and have a default behavior to keep users in db.
  2. To not cleanup local users if the local-user param is not specified.

What do you think about it? Would a contrib pull request for it would be welcomed ?
I have read the newly changed https://github.com/concourse/concourse/blob/master/CONTRIBUTING.md#signing-your-work for contributions.

Are you interested in implementing this yourself?

yes

Most helpful comment

@gaelL I think there has been some confusion about this flag. We find a lot of people treat it as a sub command. They expect to run concourse web --add-local-user test:test then start the web node normally. This is not how its intended to be used.

Instead its intended to be used as property on startup. It's basically saying start the web with all these users (you can provide the add-local-user flag multiple times). It's meant to be provided as configuration. The fact that it gets stored in the database is an implementation detail. And for what its worth the password can be provided in bcrypted format (if you're worried about that).

If you find yourself managing a large list of local users where this has become cumbersome, you could look into integrating with another auth provider (e.g. manage all your users in a team in github).

Hope this helps shed some light on the decision.

All 3 comments

@gaelL I think there has been some confusion about this flag. We find a lot of people treat it as a sub command. They expect to run concourse web --add-local-user test:test then start the web node normally. This is not how its intended to be used.

Instead its intended to be used as property on startup. It's basically saying start the web with all these users (you can provide the add-local-user flag multiple times). It's meant to be provided as configuration. The fact that it gets stored in the database is an implementation detail. And for what its worth the password can be provided in bcrypted format (if you're worried about that).

If you find yourself managing a large list of local users where this has become cumbersome, you could look into integrating with another auth provider (e.g. manage all your users in a team in github).

Hope this helps shed some light on the decision.

@gaelL I think there has been some confusion about this flag. We find a lot of people treat it as a sub command. They expect to run concourse web --add-local-user test:test then start the web node normally. This is not how its intended to be used.

Yes, I got how it is expected to be used but I think it could be a good idea to allow user to choose this behavior and satisfy everyone's needs, WDYT ?

Closing this issue, we managed do migrate using another way.

Was this page helpful?
0 / 5 - 0 ratings