Hi
I’m building a container to do backups of persistent volumes. It needs the ability to create and read snapshots (and potentially delete them) but nothing else.
It looks like at the moment, API clients can be restricted on the project level, but there’s no granular permissions over which actions it can perform.
Is this on the roadmap? What other alternatives do I have?
You can currently use OpenFGA to restrict users to specific instances: Authorization - Incus documentation
and can also write authorization scriptlets: Authorization - Incus documentation
Unrelated to question, more so for community. Maybe I could add some graphical scriptlet management tools to Ararat to make this easier to access/configure. Curious on thoughts!
Ah thanks! Don’t know how I missed that part of the docs. I’ll take a stab with a scriptlet, hopefully that will be sufficient.
May be interesting and something similar could also apply to the cloud-init config which can similarly be a bit of a black box. The main issue with this kind of approach is with reading back the data in case the user has made some modifications (or at least detection user made changes).
The scriptlet mechanism needs more examples in general I think and not just the authorization scriptlet, but also the placement scriptlet and QEMU scriptlet. Would be nice if some of the folks using those features in anger could contribute sanitized version of what they’re doing as examples.
For authorization specifically, something I suggested a couple of times to folks looking at using it is to have a pretty generic authorization scriptlet which is mostly static but then performs permission checks based on user.XYZ configuration keys set on the objects.
So you can then set a user.access.exec = foo,bar in your instance’s config and have the scriptlet allow users using client certificates with the name field set to foo or bar to do the instance exec action.
Nice, love this idea! I’ll play with it when I find the time.
Is there any documentation around the scriptlet language and API?
Sorry to insist but I can’t figure out how to get the scriptlet to query the instance for the user config. Is there any documentation or examples I can consult?
Looks like we’re missing some of those functions under the authorization scriptlet code path…
@bensmrs what do you think is best here? Should we add a bunch of get_XYZ functions for each of the object types, or is there some way we could have a more generic get_object which retrieves the full struct of the target object without needing per-type logic in Starlark?
I guess we can abuse Starlark’s loose typing with a get_object function. Would that take an API path as its argument?
Given we’re in an authorization context with a target object, it would be nice if it could just pull that object without the user having to figure out the API path for it. That would mean some logic on the Go side though.
Well we can’t guess what foo or bar mean, so we’d have to have dedicated per-object type functions.
Edit: ah! I now understand the initial question. A bit hard, but doable I think.
Looking through the code, it seems like if there’s an error when running the scriptlet, authorisation will fail - which makes sense generally.
Does this mean all API calls are rejected though, even from unrestricted certs?
Love this, would make for much nicer scriptlets and a lot less room for error!