Identity and Access Management for LXD

LXD Specifications
21

I did interpret it the way you intended so thats good :slight_smile:

22

For the internal openfga driver, we only need to implement the read parts of the driver because LXD will only be calling those, updates to the model will be materialised by direct writes to the underlying entity tables in LXD.

23

Sorry if I missed that, but what happens when a user authenticates via OIDC for the first time - what permissions do they get? No access at all since they aren’t in any group yet? Or full permission as before?
Is there a way to set the default permission for new users (apart from IdP-governed groups)?

24

New OIDC users will have no access until an administrator grants them access via a group. I don’t think it would be safe to grant new users any level of permission by default. The only way to configure defaults would be to use the IdP groups.

25

@massigori @mionaalex @egelinas @tomp @shipperizer @ru-fu @jpelizaeus I’ve updated the spec. The key changes are:

  1. Updates and additions to the definitions section, please re-read this.
  2. OpenFGA objects will now be of the form <type>:<URL>. So an instance object will be instance:/1.0/instances/{instanceName}?project={projectName}. While this introduces some redundancy in the name, this is an established and well structured method of addressing a unique resource within LXD. Many users will also be familiar with using URLs as references, for example in the “used by” field of a project or profile, or in the warnings API.
  3. The openfga_tuple_ref view has been updated and triggers have been removed. The view now makes use of sqlite JSON methods to return path elements required for input to the URL. This was required because we could not guarantee that using a forward slash as a delimiter would be reliable. Additionally, dangling permissions can no longer affect authorization decisions.
  4. The API routes for users, groups, and permissions have all been changed. Users can no longer be added to groups via the groups API and instead must be added via the users API. Additionally all routes are now grouped under /1.0/auth.
  5. The CLI commands have changed slightly, and are grouped under the auth subcommand.
1 Like
26

@markylaing for the record, my only concern with the old format was that it was “leaking” out of the user API and into the CLI, which was introducing another public-facing encoding format for resources.

If it is easier for integration with external openfga servers to have a different format in the SQL view then I don’t have an issue with that as long as that format is then converted to the URL format in the public facing API.

Eventually I think we should have a function that converts a REST resource URL to a more friendly representation that we can use in the CLI output and by using the same format everywhere when we refer to a resource we can use the same function to display resources for both “Used By” and IAM permissions.

27

It is OpenFGA that evaluates whether a user is authorized to access an object by checking whether this user has a proper relationship with this object. Clashing permissions of users belonging to different groups can be solved introducing a context or a conditional access (i.e. organization, time or other conditions, i.e. https://openfga.dev/docs/modeling/organization-context-authorization and https://openfga.dev/docs/modeling/contextual-time-based-authorization).

28

Can we use lxc auth group perm remove as we tend to use remove rather than revoke, also it helps to indicate what is being removed/revoked.

29

Happy to make this change. I assume the same for grant. So it will be:

  • lxc auth group perm add <group_name> <entity_type> [<entity_name>] <entitlement> [<key>=<value>...]
  • lxc auth group perm remove <group_name> <entity_type> [<entity_name>] <entitlement> [<key>=<value>...]

The entity name is optional only when the entity type is server.

30

Yep add instead of grant is consistent with other commands.

Do you think using lxc auth group permission is clearer rather than perm (I’m having 2nd thoughts on the short version)?

31

Perhaps we should have permission but allow an alias to perm?

1 Like
32

@massigori @shipperizer @tomp @maria-seralessandri

I’ve updated the spec. This will be what we go with for the LTS.

  • Proper handling of service accounts won’t be included but we will include the type in the OpenFGA model.
  • We have decided to omit roles from the model as they would only make sense with an accompanying API. We can add roles to a monthly release if they become a strict requirement.
  • Destructive operations have been explicitly separated in the OpenFGA model (e.g. can_delete) but some built-in roles remain to group these together into sensible use-cases.
  • There have been some further changes to the API routes. I have generated a swagger spec which can be viewed here: https://gist.github.com/markylaing/f6acd02615f5103d218c8905294a4297
2 Likes
33

subject isnt a field in this table.

34

Lets call this PermissionInfo or PermissionState as there is precedent for using these suffixes in shared/api already:

ClusterMemberSysInfo
ServerStorageDriverInfo
NetworkState
ProjectState

35

Oh actually I see there is also some *Full types too, OK then lets leave as is. :slight_smile:

36

Ah yes, missed that thanks.

37

Hrm, although InstanceFull is the only real non-deprecated example, and really is for use with recurse=2 so maybe we should still go with one of the other suffixes as there’s more of them.

38

I went with Full because it is already used for populating extra fields on instances. Happy to use Info as well but not sure if State works for this.

39

I’ll go with Info :slight_smile:

1 Like
40

Thanks for the update. I have no further comments at this stage, just one question:

What is the functional purpose of permission_manager in the server type?

As for custom roles support I can understand the reasoning behind the decision, also because I think the UXers are still working on the design.