RFC: Managing quotas about perunkeystoneadapter

[jkrue]

As you mentioned a domain admin account can't be used to set quotas. For this reason we currently run the adapter with admin privileges. This might not the best solution, but is this really a big problem ? Since the adapter do not delete resources automatically this seems to be ok for me.

[Be-El]

It's a matter of security vs. effort. I prefer to use the least privileges necessary to perform a task, even if this means extra effort in the implementation. And storing cloud admin credentials for any automated task is kind of a no-go in my opinion.

I'm preparing a branch for the necessary fixes in the current master; extensions for quota support will be added after the initial quota implementation is complete.

[hexylena]

It's fine from Freiburg's side, @jkrue. We already store cloud admin credentials (on our management nodes) for automated tasks like syncing flavor lists. Given our threat model, it isn't a big concern to likewise provide the adapter with credentials.

Glad you have the time to put in the extra effort for the extra security @Be-El.

[Be-El]

Quota management as domain admin is no problem......except for the cinder quotas. You need to add the domain admin as project admin to each managed project; retrieving and setting quotas requires as new project scope authentication token.

If the current work at the quota implementation in branch feature/transfer-quotas is finished, I would start implementing a token cache and do the necessary changes to handle cinder quotas correctly.

The important question we need to answer before:
Do we want to add the service account as project admin permanently to each project, or do we want to assign roles on the fly? How often does perun trigger the keystone adapter?

(Another alternative are nested projects.....currently evalutating)