Organizations

This page describes the concept of organizations and how different Weka system features operate within an organizational context.

Overview

For the obscuration of data between different groups of users on the same Weka system, it is possible to create multiple organizations.

The Weka system supports up to 64 organizations. Within an organization, logical entities participating in obtaining control of data are managed by the Organization Admin, and not the Cluster Admin.

The Cluster Admin can perform the following activities:

• Create new organizations (with a defined Organization Admin).

• Delete existing organizations.

• Monitor per organization the total capacity used by all the organization filesystems.

‌While Cluster Admins are people trusted by the different organizations (e.g., have root access to the backend hosts), they are obscured from the organization data in the Weka system. The Cluster Admin separation is partial, e.g., they can still see the events of all organizations. The Weka system ensures the separation of any sensitive information between the different organizations.

Note: It is not possible to separate data at the hardware level. While the Weka system is highly scalable and serves IOs fairly among filesystems, there is no QoS guarantee between organizations and system limits are per organization. Consequently, a single organization's workload or configuration can exhaust the entire cluster limits.

Use Cases for Working with Organizations

Private Cloud Multi-Tenancy

Working with organizations makes it possible to manage different departments. While this requires more configuration, e.g., different LDAP configurations are usually unnecessary between different departments in the same organization, the Cluster Admin is fully trusted. It is possible to separate and obscure specific departments - such as IT, Finance, Life Sciences, and Genomics - and even specific projects in departments.

Logical Separation of External Groups of Users

When multiple, independent groups use the same provided infrastructure, the use of multiple organizations provides much better security, obscuration, and separation of data.

Cluster Level Entities

The following entities are managed at the cluster level by the Cluster Admin:

• Hardware

• NFS service (NFS groups and IP/interfaces)

• SMB service

• Filesystem groups - definition of tiering policies for the different groups, while the Organization Admin selects the filesystem group from the predefined list of groups for each filesystem created

• KMS

Organization Level Entities

All system entities at the organization level are managed only by the relevant Organization Admin and are only viewable by users within the organization. Cluster Admins do not have permissions to view or manage these entities, which include the following:

• Filesystems, along with the ability to mount the filesystems (cannot be mounted even by the Cluster Admin)

• Object store buckets

• LDAP server

• NFS exports (NFS client permissions)

Note: SMB shares cannot be defined for organizations other than the 'Root' organization.

Note: NFS exports cannot be configured with manage-gids option for organizations other than the 'Root' organization.

Managing Organizations

Only users defined as Cluster Admins can manage organizations. When no organization is created, the root organization is the default organization and all operations are regular, i.e., it is not necessary to authenticate the mounts or supply an organization name when logging in using the GUI/CLI.

Once a new organization is created, the organization name must be provided in every login command, using the --org attribute in the weka user login command.

Usage and Quota Management

Cluster Admins can view an organization's usage (both SSD and total) and can limit usage with quotas per organization. This can be leveraged for charge-backs on either used or allocated capacity of SSD or object store data.

Managing Organizations Using the GUI

To create, delete, or view organizations in the cluster using the GUI, go to the Organizations screen.

Organizations Screen

Managing Organizations Using the CLI

Creating an Organization

Command: weka org create

Use the following command line to create an organization:

weka org create <name> <username> <password> [--ssd-quota ssd-quota] [--total-quota total-quota]

Parameters in Command Line

Name	Type	Value	Limitations	Mandatory	Default
name	String	Organization name	Must be a valid name	Yes
username	String	Username of the created Organization Admin	Must be a valid name	Yes
password	String	Password of the created Organization Admin		Yes
ssd-quota	Number	Allowed quota out of the system SSDs to be used by the organization	Must be a valid number	No	0 (not limited)
total-quota	Number	Total allowed quota for the organization (SSD and object store)	Must be a valid number	No	0 (not limited)

Viewing Organizations

Command: weka org

# weka org

ID | Name       | Allocated SSD | SSD Quota | Allocated Total | Total Quota
---+------------+---------------+-----------+-----------------+-------------
0  | Root       | 0 B           | 0 B       | 0 B             | 0 B
1  | Local IT   | 500.00 GB     | 500.00 GB | 500.00 GB       | 0 B
2  | CUSTOMER_1 | 100.00 GB     | 300.00 GB | 200.00 GB       | 900.00 GB

Editing an Organization

Renaming an Organization

Command: weka org rename

Use the following command line to rename an organization:

weka org rename <org> <new-name>

Parameters in Command Line

Name	Type	Value	Limitations	Mandatory	Default
org	String/Integer	Current organization name or ID		Yes
new-name	String	New organization name		Yes

Updating an Organization's Quotas

Command: weka org set-quota

Use the following command line to update an organization's quota:

weka org set-quota <org> [--ssd-quota ssd-quota] [--total-quota total-quota]

Parameters in Command Line

Name	Type	Value	Limitations	Mandatory	Default
org	String/Integer	Organization name or ID	The root organization (org ID = 0 cannot be limited)	Yes
ssd-quota	Number	Allowed quota out of the system SSDs to be used by the organization	Must be a valid number	No
total-quota	Number	Total allowed quota for the organization (SSD and object store)	Must be a valid number	No

Deleting an Organization

Command: weka org delete

Use the following command line to delete an organization:

weka org delete <org>

Parameters in Command Line

Name	Type	Value	Limitations	Mandatory	Default
org	String/Integer	Organization name or ID		Yes

Warning: Deleting an organization is irreversible and will also remove all entities related to the organization, such as filesystems, object stores, and users.

Organization Admin Role Privileges

When a new organization is created, the Cluster Admin creates an Organization Admin user for the organization, who is the administrator within the organization responsible for managing each organization level entity.

Organization Admins have similar privileges to Cluster Admins, except that these privileges are limited to the organization level. They can perform the following within the organization:

• Create new users

• Delete existing users

• Change user passwords

• Set user roles

• Manage the organization LDAP configuration

Additionally, to avoid situations where an Organization Admin loses access to a Weka system cluster, the following restrictions are implemented on Organization Admins:

• Cannot delete themselves

• Cannot change their role to a regular user role.

Mount Authentication for Organization Filesystems

Once the Cluster Admin has created an organization and the Organization Admin has created filesystems, users, or configured the LDAP for the organization, regular users of the organization can mount filesystems.

The purpose of organizations is to provide separation and security for organization data, which requires authentication of the Weka system filesystem mounts. This authentication of mounts prevents users of other organizations and even the Cluster Admin from accessing organization filesystems.

Mounting filesystems in an organization (other than the Root organization) is only supported using a stateless client. If the user is not logged into the Weka system, a login prompt will appear as part of the mount command.

To securely mount a filesystem in the client, first log into the Weka system:

weka user login my_user my_password --org my_org -H backend-host-0

Then mount the filesystem:

mount -t wekafs backend-host-0/my_fs /mnt/weka/my_fs

Refer to Mount Command Options for all mount options.

‌Authentication is achieved by obtaining a mount token and including it in the mount command. Logging into the Weka system using the CLI (the weka user login command) creates an authentication token and saves it in the client (default to ~/.weka/auth-token.json, which can be changed using the--pathattribute). The Weka system assigns the token that relates to a specific organization. Only mounts that pass the path to a correct token can successfully access the filesystems of the organization.

Once a user is authenticated, the mount command uses the default location of the authentication token. It is possible to change the token location/name and pass it as a parameter in the mount command using the auth_token_path mount option, or theWEKA_TOKEN environment variable.

mount -t wekafs backend-host-0/my_fs /mnt/weka/my_fs -o auth_token_path=<path>

This is useful when mounting several filesystems for several users/organizations on the same host or when using Autofs.

When a token is compromised or no longer required, such as when a user leaves the organization, the Organization Admin can prevent using that token for new mounts by revoking the user access.

Revoking User Access Using the CLI

Command: weka user revoke-tokens

Use the following command to revoke internal user access to the system and mounting filesystems:

weka user revoke-tokens <username>

For LDAP users, access can be revoked by changing the user-revocation-attribute defined in the LDAP server configuration.

Parameters in Command Line

Name	Type	Value	Limitations	Mandatory	Default
username	String/Integer	Valid user in the organization of the Organization Admin running the command		Yes

Note: NFS and SMB are different protocols from WekaFS which require additional security considerations when used, e.g., NFS permissions are granted per host, so permissions for accessing these hosts for NFS export should be handled carefully.