Offloading accounts & permissions to external source

[bittermandel]

As it looks right now, Keppel seems to depend on operators creating accounts in the Keppel database and set permissions for them there. This does not really fit into many environments, as operators generally store their authentication & authorization data in a centralized store and distribute it at that layer.

Would there be a possibility to consider moving it into an interface so it can be extended? We'd love to handle all authz/n externally from Keppel.

[SuperSandro2000]

We are configuring keppel through elektra which in the background uses keppels' API. Elektra is built to work with openstack and probably not easily adapted to be used in a more generic environment. We have a handful of accounts which we configure globally with a simple script through the API and the vast majority is done by the customers, as we only offer the registry platform.

OpenStack is designed around "domains" in which admins can create the keppel accounts where users can then do their things. Since we are all admins, we probably didn't notice yet that some of those settings are not as convenient and generic designed. If you are referring to this part.
So you're usecase would be that polices/RBACPolicies checked here or taken here when creating the account are taken from a central place through an extensible driver instead of from the database? Did I understand that correct?

But the generic request authz should already be extensible through the auth driver https://github.com/sapcc/keppel/blob/master/internal/auth/request.go#L139
If a handful of functions should be moved into the auth driver, then I think that's easily possible. If we would need to create a complete new interface, then I would first design that with @majewsky .

Can you point a specific code path or api request you have in mind that is now hardwired into keppel to help me better understand your use case?

[majewsky]

There is some potential for synergy here that the proposal by @bittermandel is bringing into focus for me. I was already thinking about how to deal with our account seeding moving forward, since running it manually is tedious and automating it in a blackbox manner has some challenges around account name claiming.

What do you think about a new driver interface like this?

type AccountManagementDriver interface {
    // Called by a jobloop for every account every once in a while (e.g. every hour).
    //
    // Returns an updated account object if the account is managed.
    // The jobloop will apply the account in the DB accordingly.
    //
    // Returns nil if the account was managed, and now shall be deleted.
    //The jobloop will clean up the manifests, blobs, repos and the account.
    //
    // Returns ErrSkipAccount if the account is not managed.
    // The jobloop will leave the account unchanged.
    ConfigureAccount(account keppel.Account, rbacs []keppel.RBACPolicy) (keppel.Account, []keppel.RBACPolicy, error)

    // Called by a jobloop every once in a while (e.g. every hour).
    // If names are added to the list, the jobloop will create the
    // respective accounts as configured by ConfigureAccount().
    // If names are removed from the list, Keppel will delete the
    // respective accounts (including all manifests, blobs and repos).
    ManagedAccountNames() ([]string, error)
}

var ErrSkipAccount = errors.New("account is not managed")

Then we could have one driver for ourselves driven by a static seed file, and @bittermandel can have a driver that connects to their auth system. ConfigureAccount() is designed to be intentionally vague in scope: Our seed driver would just overwrite basically everything to conform to the seeded config, whereas @bittermandel's driver can be as selective about which fields it maintains on existing accounts as it needs.

[majewsky]

I let the above design simmer in my head for a few days and did not see any obvious problems with it. I did #349 and #351 as a bit of a prerequisite for the addition of this new driver interface, and I will probably have @SuperSandro2000 drive the implementation of the new driver interface as well as the driver implementation for our seeding usecase.