Authorization Model

The SysEleven IAM is based on OpenFGA, a CNCF project that provides a flexible and efficient authorization system.

Technical Detail

Not all permissions listed here are available for configuration through the SysEleven IAM Dashboard. Some permissions are assigned based on complex workflows and are not directly configurable.

Organization Permissions

Permission Inheritance

Organization permissions may grant wide-ranging permissions to other resources, like projects, service accounts and teams.

The following permissions can be assigned for organizations:

Permission Name	Assignable To	Description
owner	user	Grants full ownership rights over the organization
admin	user, service_account	Grants administrative privileges for the organization
member	user, api_key, service_account, team#member	Basic membership in the organization
can_become_project_administrator_in_org	user, service_account, team#member	Allows becoming a project administrator within the organization
can_create_service_accounts_in_org	user, service_account, team#member	Enables creating service accounts in the organization
can_create_projects_in_org	user, service_account, team#member	Enables creating new projects within the organization
can_invite_members_in_org	user, service_account, team#member	Allows inviting new members to the organization
can_crud_permissions_in_org	user, service_account, team#member	Grants the ability to create, view, update, and delete permissions within the organization
can_read_members_in_org	user, service_account, team#member	Permits viewing the list of members in the organization
can_delete_members_in_org	user, service_account, team#member	Allows removing members from the organization
can_create_teams_in_org	user, service_account	Allows creating teams within the organization
can_manage_contact_persons_in_org	user, service_account, team#member	Allows managing contact persons for the organization
can_read_contact_persons_in_org	user, service_account, team#member	Permits viewing contact person details for the organization

Team Permissions

The following permissions can be assigned for teams:

Permission Name	Assignable To	Description
can_manage_team_in_team	user, service_account	Allows managing all aspects of the team
can_crud_team_in_team	user, service_account	Enables creating, viewing, updating, and deleting team settings
can_crud_permissions_in_team	user, service_account	Grants ability to manage permissions within the team
can_crud_members_in_team	user, service_account	Allows adding, viewing, and removing team members
member	user, service_account	Designates membership in the team

Service Account Permissions

The following permissions can be assigned for service accounts:

Permission Name	Assignable To	Description
can_manage_service_account_in_service_account	user, service_account, team#member	Allows full management of the service account
can_crud_permissions_in_service_account	user, service_account, team#member	Grants ability to manage permissions for the service account
can_crud_credentials_in_service_account	user, service_account, team#member	Enables managing credentials for the service account

Project Permissions

All permissions listed below are available in the project scope.

Permission Name	Assignable To	Description
can_become_administrator_in_project	user, service_account, team#member	Grants administrative rights for the project
can_crud_permissions_in_project	user, service_account, team#member	Allows managing permissions within the project
can_read_project_in_project	user, service_account, team#member	Enables viewing project details
can_delete_project_in_project	user, service_account, team#member	Permits deleting the project
can_create_api_keys_in_project	user, service_account, team#member	Allows creation of API keys in the project
can_read_api_keys_in_project	user, service_account, team#member	Permits viewing API keys in the project

OpenStack Permissions

OpenStack improvements

We're currently working on improving the OpenStack permissions model by introducing further roles that can be assigned to users, service accounts and teams.

Permission Name	Assignable To	OpenStack role	Description
can_become_reader_in_openstack or can_become_viewer_in_openstack	user, service_account, team#member	reader	General read access to all project resources.
can_become_member_in_openstack or can_become_editor_in_openstack	user, service_account, team#member	member	Default write access to project resources; implies reader.
can_become_compute_member_in_openstack	user, service_account, team#member	compute_member	Manage compute resources; read related services.
can_become_block-storage_member_in_openstack	user, service_account, team#member	block-storage_member	Manage block storage service resources.
can_become_image_member_in_openstack	user, service_account, team#member	image_member	Manage image service resources.
can_become_network_member_in_openstack	user, service_account, team#member	network_member	Manage network service resources.
can_become_network_security_member_in_openstack	user, service_account, team#member	network-security_member	Manage network security groups, security group rules and FWaaS resources.
can_become_dns_member_in_openstack	user, service_account, team#member	dns_member	Manage DNS service resources.
can_become_load-balancer_member_in_openstack	user, service_account, team#member	load-balancer-member	Manage load balancer resources.
can_become_shared-file-system_member_in_openstack	user, service_account, team#member	shared-file-system_member	Manage shared file system resources.
can_become_key-manager_member_in_openstack	user, service_account, team#member	key-manager_member	Manage secret (key manager) resources.

OpenStack policies

OpenStack policies are not only relying on the roles (permissions above), but also evaluate a set of additional properties. Therefore it should not be expected, that only having the relevant permission is enough.

<SERVICE>_member roles represent a member role isolated to the single service. This gives possibility to have OpenStack users being able to have a reduced set of privileges only for the necessary service (i.e. a certain user can only manage DNS service by granting only a can_become_dns_member_in_openstack permission). A member role (or can_become_member_in_openstack) is equal to granting all individual <SERVICE>_member roles together.

Examples

Some OpenStack services need to communicate with other services to perform a certain operation. This may lead to the fact that only member permission for that service is not sufficient.

• Usually listing resources and obtaining details about the certain resource require at least the reader role, which maps to can_become_reader_in_openstack permission.

• Downloading image data requires image_member role.

• Managing security groups and rules as well as Firewall-as-a-Service (FWaaS) groups, policies and rules requires network-security_member or network_member role. network_member role implies network-security_member role meaning that a user having the network_member can also perform security groups management operations as well as FWaaS management operations, but not the vice versa.

• Provisioning a server (VM) requires a combination of roles since it usually requires also attaching a network, storage, access to the image. There are multiple different ways how servers may be provisioned (with storage or ephemeral storage only, with or without network accesses, from other instance, etc.) necessary roles would vary. Typically at the very minimum the compute_member role is absolutely required. A server with non-ephemeral storage would require block-storage_member role. A server provisioned from the image requires image_member role. Any networking require network_member additionally.

• Modifyng an already existing server will also require additional roles depending on the operation being performed: change of the networking or security groups of the server requires network_member, changing volume attachments require block-storage_member role.

• Server actions (i.e. reboot, shutdown) normally only require the compute_member role, unless, as mentioned above, those modify server networkig or storage attached.

• Any load balancing operation require load-balancer-member role being granted.

Metakube Permissions

Permission Name	Assignable To	Description
can_create_clusters_in_metakube	user, service_account, team#member, api_key	Enables creating Kubernetes clusters
can_read_clusters_in_metakube	user, service_account, team#member, api_key	Allows viewing Kubernetes clusters
can_update_clusters_in_metakube	user, service_account, team#member, api_key	Enables modifying Kubernetes clusters
can_delete_clusters_in_metakube	user, service_account, team#member, api_key	Permits deleting Kubernetes clusters
can_create_ssh_keys_in_metakube	user, service_account, team#member, api_key	Enables adding SSH keys for cluster access
can_read_ssh_keys_in_metakube	user, service_account, team#member, api_key	Allows viewing SSH keys
can_update_ssh_keys_in_metakube	user, service_account, team#member, api_key	Enables modifying SSH keys
can_delete_ssh_keys_in_metakube	user, service_account, team#member, api_key	Permits removing SSH keys

DBaaS Permissions

Permission Name	Assignable To	Description
can_create_databases_in_dbaas	user, service_account, team#member, api_key	Enables creating database instances
can_read_databases_in_dbaas	user, service_account, team#member, api_key	Allows viewing database instances
can_update_databases_in_dbaas	user, service_account, team#member, api_key	Enables modifying database instances
can_delete_databases_in_dbaas	user, service_account, team#member, api_key	Permits deleting database instances
can_read_backups_from_databases_in_dbaas	user, service_account, team#member, api_key	Allows viewing database backups

Observability Permissions

Permission Name	Assignable To	Description
can_become_reader_in_observability	user, service_account, team#member	Grants read-only access to observability data
can_become_editor_in_observability	user, service_account, team#member	Allows modifying observability configurations
can_become_admin_in_observability	user, service_account, team#member	Grants full administrative rights to observability
can_read_logs_in_observability	service_account, api_key	Enables reading logs
can_write_logs_in_observability	service_account, api_key	Allows sending logs to the observability platform
can_read_metrics_in_observability	service_account, api_key	Enables reading metrics
can_write_metrics_in_observability	service_account, api_key	Allows sending metrics to the platform
can_write_alertmanager_in_observability	service_account, api_key	Permits managing alert configurations
can_read_alertmanager_in_observability	service_account, api_key	Enables viewing alert configurations
can_write_rules_in_observability	service_account, api_key	Allows creating and modifying alerting rules
can_read_rules_in_observability	service_account, api_key	Enables viewing alerting rules

Object Storage Permissions

Permission Name	Assignable To	Description
can_read_s3_users_in_object_storage	user, service_account, team#member	Allows viewing S3 user accounts
can_create_s3_users_in_object_storage	user, service_account, team#member	Enables creating S3 user accounts
can_delete_s3_users_in_object_storage	user, service_account, team#member	Permits deleting S3 user accounts

Invitation Permissions

The following permissions can be assigned for invitations:

Permission Name	Assignable To	Description
invitee	user	Designates the user receiving the invitation
can_accept_invitation	user (invitee)	Allows accepting the invitation
can_delete_invitation	user	Permits cancelling the invitation