Run the OpenFGA server with docker:
docker run -p 8080:8080 -p 8081:8081 -p 3000:3000 openfga/openfga run
Run the tests:
go test -v .
To iterate, edit the model in lxd.openfga
, then run make update-openfga
, and re-run the tests.
Specification: https://discuss.linuxcontainers.org/t/lxd-rebac-authorization-using-openfga/17094#authorization-model-5
- Follows current RBAC model closely (except for adding more fine-grained permissions for network ACLs and network zones).
- Relies on the creation of an "admin" group which is not stated in model.
- Following the guides on the OpenFGA website, in most cases we should be able to check permissions with a single question: Can user U perform action A on object O? However, in the current model we need to check: Does user U have relation member with group admin OR can user U perform action A on object O?
- Juju model has 157 entitlements (relations). LXD may not be quite as complicated as Juju but the current model is not a fine-grained as it maybe should be.
See lxd.openfga
. In the Canonical terminology:
- Resources: These are
types
. - Entitlements: Any relation that looks like
can_do_thing
. - Roles: These are relations like
admin
,manager
, oroperator
that are referenced by other relations and relations of child resources. - Users: This is also a
type
that represents a single user. Users can be granted direct access on all entitlements. - Groups: This is a
type
that has a direct relationmember
touser
. Groups can also be granted direct access on all entitlements.
Some key points:
- A top level type
server
is created, representing a LXD server or cluster. - The relation
admin
defined onserver
grants edit permissions on every resource in the cluster. - The relation
operator
defined onserver
grants permissions to create and manage projects, but not to edit the cluster itself. - The relation
viewer
defined onserver
grants permission to view all cluster resources. - The relation
user
is a type bound public access for any authenticated user. This should be used for the/1.0
endpoint (server:can_view_server
). - There are then a number of relations allowing creation of specific resources. For example, a group with
server:operator
privileges could be granted access to manage certificates with the tuple:
User: group:operators#member
Relation: can_create_certificates
Object: server:lxd
- Generally, if a resource does not have any child resources then it has
manager
,viewer
,can_edit
, andcan_view
.manager
andviewer
are added to allow access to a resource via a direct access.can_edit
andcan_view
are the relations we will perform checks against. These relations usually contain an inherited relation from a parent. - The
project
type follows a similar pattern toserver
in that there is amanager
who can edit the project and all resources within, anoperator
who can create resources within the project but not edit the project configuration, and aviewer
who can view all project resources but not edit them. There are also a number of relations for creating specific kinds of resources within a project. - When permitting a user or group the
manager
oroperator
relation on a project, we also need to give themserver:viewer
so that they can view say a cluster group and be able to target it when creating an instance. - The
instance
type contains a number of extra relations representing actions that can be performed on an instance:manager
can perform any action on an instance.operator
can change the instance state and manage backups/snapshots, but cannot edit instance config.viewer
can view the instance config.user
can interact with the instance via file push/pull, sftp, console, and exec. (E.g. ssh access but better).
server:admin
creates a project and grants a groupproject:operator
permission on that project (plusserver:viewer
). Members of the group can create and manage resources in the project but cannot change project configuration (which could escalate privileges).project:operator
creates an instance and grants a userinstance:user
permission. The user can connect to the instance but not edit it.
- What happens when the authentication method changes?
- If not using Canonical OpenFGA, how does an administrator change permissions for a user or group?
- What name do we give the top-level
server
object? Or is there a way to make it singular? - What to do about operations and warnings?
a. Which users can cancel an operation? (My guess is
project:operator
but maybe we just have it asserver:user
, since you must have received a UUID from a protected endpoint? b. Should all users be able to view operations? c. Who needs to view cluster warnings? Who needs to access project specific warnings?