#3553 Service accounts in Pagure
Opened 2 years ago by karsten. Modified 2 years ago

It might be useful to have some scripts that do various operations in pagure. We should consider investigating how hard it would be to add service accounts to Pagure, so that the bots would not need to run directly as people who run them, but as separate entities.

An example for this is a bot that syncs changes from Github to Pagure (syncs == creates pull requests from upstream-merged PRs) for multiple repos. Right now, we would have to run it under a user account. Ideally, we would be able to create a bot account and use that.

The service account needs to be able to create forks under its name, be able to push to these forks (=>needs to be able to set up ssh keys) and there has to be a way to create an API token for it (preferrably with a longer life span).

Metadata Update from @karsten:
- Issue tagged with: RFE

2 years ago

Between API token and deploy keys I think this is covered.

If there are actions that are missing, we should add them to the API.

I don't think we want another mechanism for this, so I'm inclined to close this ticket as Invalid. What do you think?

The aspect that the bot runs under a specified user is imho a feature, it ties that bot with someone who is going to be accountable for the action of the bot.

In addition, there is nothing preventing anyone from creating a dedicated account for that bot.

@pingou The problem with this is that not having service accounts is a problem when people's accounts are terminated, even though the service is maintained separately. It also means it's harder to identify whether it is a bot verses a regular user.

For example, at my workplace, using regular users for this became a problem when those people left the company and their accounts were globally disabled.

Having service/bot accounts means we can create specific users that are used for interacting with Pagure irrespective of the login mechanism (that is, if local is not the auth mechanism, then you can still create "local" accounts for services/bots).

@pingou I totally agree with what @ngompa said.

The problem with accountability could (and should) be solved by assigning people/groups as maintainers of the bot (there shouldn't be a bot without maintainers).

Another advantage of having a bot (on top of what @ngompa said) is that you can easily distinguish actions done by the bot and by the actual user who owns the bot - you don't have that kind of distinction if you just use API tokens and deploy keys, because everything is "done by the user". So if the bot gets broken, you can isolate actions done by the service account and reverse them while keeping the owner's actions intact.

I think basically we need a way to:

  • create, edit and delete a bot account (I think we don't need to do this via UI initially, we can just do this via API)
  • add an attribute to the User class that specifies whether or not this account is a bot
  • create and revoke API keys for the bot (again, just API is fine)
  • add and remove SSH keys for the bot

One issue I foresee with this if we put it in the users table is: how do we deal with the situation where:

  • user foo creates a bot account with the name: betatester
  • a new user creates the account betatester in the remote account system (FAS, LDAP....)
  • user betatester tries to log into the pagure instance

We end up with an username conflict not easy to deal with.

One way around that may be to simply has a different database structure for bots than for users.

What do you think?

A separate database structure for service accounts makes sense. The key is that they are not tied to the regular user authentication method.

This also means you could add a service account "admin" field and map that to a real user, so that there is a sense of "responsibility" for it. This would have to be transferable via API to other users by an admin.

+1 for separate database structure.

Metadata Update from @karsten:
- Issue assigned to karsten

2 years ago

This requires:

  • a new database structure to store bot accounts
  • figuring out the ACLs for who can configure things for the bot (create API keys, upload ssh keys)
  • new API/UI around this
  • tests
  • docs

Rough time estimate: three weeks

A couple of questions:
- Who should be able to create a bot account ? Only Pagure admins or a selected group of user accounts (bot admins) ?
- Are bot admins global for all bots or specific to one bot ?

Thinking about this further, I think it may be problematic to have bots as a separate database table. If you imagine all the things that you'd want bots to be able to do (like adding comments to issues/PRs), you'd need to adapt comments to have either normal user or a bot as author - this complicates a lot of things, IMO.

I think it may actually make more sense to have bots in the standard users table with is_bot=True and do some name mangling. E.g. we could prohibit creating users with : in their name and enforce that every bot has name bot:actualname (or something similar). This would also give a clear visual indication to users on e.g. what account is a bot and what account is a human.

Would that make sense @pingou @ngompa @karsten ?

Login to comment on this ticket.