Manage CIDR-based security policies

Manage CIDR-based security policies to control access to WEKA clusters based on client IP address ranges, enhancing security and simplifying administration.

Overview

CIDR-based policies allow administrators to control access to WEKA cluster management and filesystems over POSIX clients by specifying permitted and restricted IP address ranges. This network-level security measure complements traditional user authentication, providing tenants with finer control over cluster access.

Key benefits:

• Enhanced security: Restrict access to the cluster by controlling which clients can connect based on their IP addresses.

• No authentication required: Secure access through network-level restrictions, simplifying management for trusted environments.

• Simplified management: Centralized control over client access without needing user credentials.

Guidelines and considerations

When implementing CIDR-based security policies in WEKA, consider the following:

• Role requirement: Only users with the ClusterAdmin role can manage security policies for the root tenant. For non-root tenant, only the TenantAdmin can manage security policies.

• Active mounts remain unaffected: Client revocation is disabled, meaning any changes to policies do not impact active mounts. This ensures ongoing connections remain stable until they are manually disconnected.

• Policy order matters: The order in which policies are attached determines the filtering sequence. For example, if the first policy denies access from IP1 and IP2, and the second policy allows IP1, the first policy takes precedence, overriding subsequent policies. Always review the order to ensure the desired access control.

• Default access behavior: Clients without a related policy are allowed by default. To secure your tenant or filesystem, always include a final policy that denies access to all other IPs after attaching the necessary policies.

Policy type restrictions

Security policies have discrete scopes. The scope of a policy is determined by the attributes it contains, and that scope controls where the policy can be attached. Mixing attributes from different scopes in a single policy is not permitted.

WEKA enforces three discrete policy types:

• API authentication policies include roles and can only be attached to tenants. They cannot be attached to filesystems or used as join policies.

• Filesystem policies include a read-only or squash-mode attribute and can only be attached to filesystems. They cannot include roles.

• Join policies can only contain an IP range. They cannot include roles or filesystem attributes.

Combining attributes from more than one policy type in a single policy is not permitted.

Policy creation and update rules

When creating or updating a security policy, the following restrictions apply:

• A policy cannot combine roles with read-only or squash-mode attributes. These attributes belong to different scopes and cannot coexist in a single policy.

• A policy that includes read-only or squash-mode must use allow as its action. The deny action is not permitted for filesystem-scoped policies.

• Updating an in-use policy is subject to scope restrictions:

  • If a policy is attached to a filesystem or join list, its roles attribute cannot be modified.

  • If a policy is attached to a tenant or join list, its read-only or squash-mode attributes cannot be modified.

  • The description and IP address ranges can always be updated regardless of where a policy is in use.

Policy attachment rules

The following table summarizes where each policy type can be attached:

Policy attributes	Attach to tenant	Attach to filesystem	Attach to join list
IP range only	Yes	Yes	Yes
Roles (with or without IP range)	Yes	No	No
read-only or squash-mode (with or without IP range)	No	Yes	No
Roles combined with read-only or squash-mode	Not permitted at creation	Not permitted at creation	Not permitted at creation

In addition, a policy already in use by one scope cannot be attached to a different scope:

• A policy attached to a filesystem cannot be attached to a tenant or join list.

• A policy attached to a tenant cannot be attached to a filesystem or join list.

• A policy attached to a join list cannot be attached to a tenant or filesystem.

Legacy policies

Existing policies that contain attributes incompatible with current scope restrictions remain functional without modification. However, they are restricted from further changes to the conflicting attributes. Only unaffected fields, such as description and IP address ranges, can be updated on these policies. To change restricted attributes, create a new policy that conforms to current scope requirements.

Squash mode

Squash mode specifies how the storage system maps incoming User IDs (UID) and Group IDs (GID) to manage access permissions and security. The following values are supported:

• none: The filesystem trusts and preserves the original UID/GID provided by the client. Use this mode when precise POSIX permission enforcement is needed across the cluster.

• root: Maps all requests from UID 0 (root) to an anonymous, non-privileged user (typically nobody). Use this to prevent a user with root access on a client machine from gaining administrative privileges on the WEKA filesystem.

• all: Maps every incoming request, regardless of the original UID/GID, to a single anonymous identity. Use this to simplify access for shared or public data repositories where individual user tracking is not required.

Default: none

Squash mode governs the native WEKA client only. For other protocols (NFS, SMB, S3), configure squash settings independently within their respective export or share settings.

Root-squash enforcement and client version compatibility

• Root-squash is enforced only on clients that were either freshly installed or upgraded using a standard umount/mount cycle (not a hot upgrade).

• For clients upgraded by hot upgrade, perform a umount/mount cycle on the affected client after the upgrade.

Policy capacity

• 16 policies can be assigned per tenant.

• 16 policies can be assigned per filesystem.

• 8 policies are allowed per client or backend join.

• Each policy supports up to 32 IP address ranges.

• A total of 5,120 policies can be defined system-wide.

Manage security policies

Add and manage security policies so that you can apply them on the tenant or filesystem. You can perform the following:

• List security policies defined in the WEKA cluster.

• Display information about a specific security policy.

• Add a new security policy.

• Remove a security policy.

• Duplicate an existing security policy, creating a new one.

• Update the settings of an existing security policy.

• Simulate the effect of one or more security policies.

• List security policies applied when joining containers.

• Set security policies for joining cluster, replacing the existing set of policies.

• Attach a security policy when joining cluster.

• Detach a security policy when joining cluster.

• Remove all security policies applied when joining cluster

List security policies

Command: weka security policy list

Use the following command line to list security policies defined in the WEKA cluster.

weka security policy list [--action action] [--roles roles]...[--ips ips]...[--squash-mode squash-mode] [--anon-uid anon-uid]  [--anon-gid anon-gid]

Parameters

Parameter	Description
action	Lists security policies that match a specific action. (format: allow or deny).
roles...	Lists security policies that include specific roles. (format: clusteradmin, tenantadmin, regular, readonly or s3, may be repeated or comma-separated).
ips...	Lists security policies that include specific IP address ranges. (format: IP or IP/CIDR or IP1-IP2 or A.B.C.D-E, may be repeated or comma-separated).
squash-mode	Filters policies by squash mode. For a description of each value, see Squash mode.
anon-uid	Filters by the anonymous UID configured in the policy. Default: 65534
anon-gid	Filters by the anonymous GID configured in the policy. Default: 65534

Display information of a security policy

Command: weka security policy show

Displays information about a specific security policy.

weka security policy show <policy>

Parameters

Parameter	Description
policy*	Name or ID of security policy.

Add a new security policy

Command: weka security policy add

Use the following command line to add a new security policy.

weka security policy add <name> [--description description] [--action action] [--read-only read-only]  [--anon-uid anon-uid] [--anon-gid anon-gid] [--squash-mode squash-mode] [--ips ips]...[--roles roles]...

Parameters

Parameter	Description
name*	Name of the new security policy. (up to 64 alphanumeric characters, hyphens (-), underscores (_), and periods (.), starting with a letter).
description	Description of the security policy. (up to 256 characters).
action	Whether access is granted or denied when the security policy matches. (format: allow or deny).
read-only	The security policy allows read-only mounts only. Cannot be combined with squash-mode or roles attributes. (format: yes, no, true, false, on, off, y or n).
squash-mode	Specifies how the storage system maps incoming UIDs and GIDs. Cannot be combined with read-only or roles attributes. For a description of each value, see Squash mode. Default: none
anon-uid	An anonymous UID to replace the root user when root squashing is enabled. Default: 65534
anon-gid	An anonymous GID to replace the root user when root squashing is enabled. Default: 65534
ips...	IP address ranges to which the security policy applies. (format: IP or IP/CIDR or IP1-IP2 or A.B.C.D-E, may be repeated or comma-separated).
roles...	User roles to which the security policy applies. Cannot be combined with read-only or squash-mode attributes. (format: clusteradmin, tenantadmin, regular, readonly or s3, may be repeated or comma-separated).

A policy cannot combine roles with read-only or squash-mode. A policy that includes read-only or squash-mode must use allow as its action. The deny action is not permitted for filesystem-scoped policies.

Example

The following example creates a policy that allows access by users with the clusteradmin role from two specific subnets:

weka security policy create admin_network --action allow --ips 10.1.0.0/16,10.2.1.0/24 --roles clusteradmin

Remove a security policy

Command: weka security policy remove

Use the following command line to delete a security policy.

weka security policy remove <policy>

Parameters

Parameter	Description
policy*	Name or ID of security policy.

Duplicate an existing security policy

Command: weka security policy duplicate

Use the following command line to duplicate an existing security policy, creating a new one.

weka security policy duplicate <policy> <name>

Parameters

Parameter	Description
policy*	Name or ID of the security policy to duplicate.
name*	Name of the new security policy. (up to 64 alphanumeric characters, hyphens (-), underscores (_), and periods (.), starting with a letter).

Example

weka security policy duplicate sourcePolicy newPolicyName

Update security policy settings

Command: weka security policy update

Use the following command line to update the settings of an existing security policy.

weka security policy update <policy> [--description description] [--action action] [--new-name new-name] [--roles roles]... [--add-roles add-roles]... [--remove-roles remove-roles]... [--ips ips]... [--add-ips add-ips]... [--remove-ips remove-ips]...[--squash-mode squash-mode] 
P

Parameters

Parameter	Description
policy*	Name or ID of security policy.
--description	Updates the description of the security policy. (up to 256 characters).
--action	Changes whether access is granted when the security policy matches. (format: allow or deny).
--new-name	New name of the security policy. (up to 64 alphanumeric characters, hyphens (-), underscores (_), and periods (.), starting with a letter).
--roles...	User roles to which the security policy applies. (format: clusteradmin, tenantadmin, regular, readonly or s3, may be repeated or comma-separated).
--add-roles...	User roles to append to the security policy. (format: clusteradmin, tenantadmin, regular, readonly or s3, may be repeated or comma-separated).
--remove-roles...	User roles to remove from the security policy. (format: clusteradmin, tenantadmin, regular, readonly or s3, may be repeated or comma-separated).
ips	IP address ranges to which the security policy applies. (format: IP or IP/CIDR or IP1-IP2 or A.B.C.D-E, may be repeated or comma-separated).
add-ips	IP address ranges to append to the security policy. (format: IP or IP/CIDR or IP1-IP2 or A.B.C.D-E, may be repeated or comma-separated).
remove-ips	IP address ranges to remove from the security policy. (format: IP or IP/CIDR or IP1-IP2 or A.B.C.D-E, may be repeated or comma-separated).
squash-mode	Updates the squash mode of the security policy. Cannot be combined with read-only or roles attributes. For a description of each value, see Squash mode. Default: none

• Modifying roles, squash-mode, or read-only on a policy may be restricted depending on where the policy is currently attached.

• If the policy is attached to a filesystem or join list, roles cannot be modified.

• If the policy is attached to a tenant or join list, squash-mode and read-only cannot be modified.

• The description and IP address ranges can always be updated. To change restricted attributes, create a new policy with the required configuration.

Example

The following example adds the readonly role and updates the description of the existing admin_network policy:

weka security policy update admin_network --add-roles readonly --description "Limit Cluster Admin Access to HQ Network"

Simulate the effect of one or more security policies

Command: weka security policy test

Use the following command line to simulates the effect of one or more security policies.

weka security policy test [--role role] [--ip ip] [--join] [<policy>]...

Parameters

Parameter	Description
policy...	Policies to evaluate, with access verified in the order listed.
role	Simulate effect of policies on API access from the given user role. (format: clusteradmin, tenantadmin, regular, readonly or s3)
ip	IP address to evaluate as the source address.
join	Simulate effect of policies when joining the cluster.

Example

weka security policy test policy1 policy2 policy3 --ip 10.2.1.0 --role clusteradmin

List security policies applied when joining containers

Command: weka security policy join list

Use the following command line to list security policies applied when joining containers.

weka security policy join list [--client] [--backend]

Parameters

Parameter	Description
client	List policies for clients.
backend	List policies for backends.

Set security policies for joining cluster

Command: weka security policy join set

Use the following command line to set security policies for joining cluster, replacing the existing set of policies.

weka security policy join set [--client] [--backend] [<policies>]...

Parameters

Parameter	Description
policies...	Security policy names or IDs applied to cluster join process.
client	Apply policies to clients.
backend	Apply policies to backends.

Attach a security policy when joining cluster

Command: weka security policy join attach

Use the following command line to attach security policies applied when joining cluster, adding them to the existing policies.

weka security policy join attach [--client] [--backend] [<policies>]...

Parameters

Parameter	Description
policies...	Security policy names or IDs to attach to cluster join process.
client	Apply policies to clients.
backend	Apply policies to backends.

Only policies that contain IP ranges only, with no roles, read-only, or squash-mode attributes, can be attached to the join list. Policies already in use by a filesystem or tenant cannot be attached to the join list.

Detach a security policy when joining cluster

Command: weka security policy join detach

Use the following command line to remove security policies applied when joining cluster.

weka security policy join detach [--client] [--backend] [<policies>]...

Parameters

Parameter	Description
policies...	Security policy names or IDs to remove from cluster join process.
client	Apply policies to clients.
backend	Apply policies to backends.

Remove all security policies applied when joining cluster

Command: weka security policy join reset

Use the following command line to remove all security policies applied when joining cluster.

weka security policy join reset [--client] [--backend]

Parameters

Parameter	Description
client	Apply policies to clients.
backend	Apply policies to backends.

Manage tenant-level security policies

Once security policies are established, you can manage them at the tenant level by performing the following tasks:

• List security policies for a specific tenant.

• Set security policies for a specific tenant.

• Remove all security policies from a specific tenant.

• Attach new security policies to a specific tenant.

• Detach security policies from a specific tenant.

• Revoke all API tokens issued for a specific tenant.

Role requirement: To manage security policies, users must hold specific roles. For the root tenant, only those with the ClusterAdmin role have this capability. In contrast, for non-root tenants, this responsibility is designated to users with the TenantAdmin role.

List the tenant security policies

Command: weka tenant security policy list

Use the following command to list the security policies of a specified tenant.

weka tenant security policy list <tenant>

The command weka tenant also displays the attached policies for each tenant.

Parameters

Parameter	Description
tenant*	Tenant name or ID.

Set security policies for a tenant

Command: weka tenant security policy set

Use the following command to set security policies for a tenant, replacing the existing list of policies. If setting multiple policies, separate each with a space.

weka tenant security policy set <tenant> [<policies>]...

Parameters

Parameter	Description
tenant*	Tenant name or ID.
policies...	Security policy names or IDs to assign them to the tenant, separated by spaces.

Remove all security policies from a tenant

Command: weka tenant security policy reset

Use the following command to removes all security policies from a tenant.

weka tenant security policy reset <tenant>

Parameters

Parameter	Description
tenant*	Tenant name or ID.

Attach new security policies to a tenant

Command: weka tenant security policy attach

Use the following command to attach new security policies to an tenant, adding them to the existing policies. If attaching multiple policies, separate each with a space.

weka tenant security policy attach <tenant> [<policies>]...

Parameters

Parameter	Description
tenant*	Tenant name or ID.
policies...	Security policy names or IDs to attach to the tenant, separated by spaces.

Only policies that do not contain read-only or squash-mode attributes can be attached to a tenant. Policies already in use by a filesystem or join list cannot be attached to a tenant.

Detach security policies from a tenant

Command: weka tenant security policy detach

Use the following command to detach (remove) security policies from a tenant. For detaching multiple policies, separate each with a space.

weka tenant security policy detach <tenant>[<policies>]...

Parameters

Parameter	Description
tenant*	Tenant name or ID.
policies...	Security policy names or IDs to detach from the tenant, separated by spaces .

Revoke all API tokens issued for a tenant

Command: weka tenant security revoke-tokens

Use the following command to revoke all API tokens issued for a specific tenant.

weka tenant security revoke-tokens <tenant>

Parameters

Parameter	Description
tenant*	Tenant name or ID.

Manage filesystem security policies

Once security policies are defined, you can perform the following tasks at the filesystem level:

• List security policies for a specified filesystem.

• Set security policies for a specified filesystem.

• Remove all security policies from a specified filesystem.

• Attach new security policies to a specified filesystem.

• Detach security policies from a specified filesystem.

List security policies for a filesystem

Command: weka fs security policy list

Use the following command to list security policies for a specified filesystem.

weka fs security policy list <fs-name>

Parameters

Parameter	Description
fs-name*	Filesystem name.

Set security policies for a filesystem

Command: weka fs security policy set

Use the following command to set security policies for a specified filesystem, replacing the existing list of policies. If setting multiple policies, separate each with a space.

weka fs security policy set <fs-name> [<policies>]...

Parameters

Parameter	Description
fs-name*	Filesystem name.
policies...	Security policy names or IDs to set for a filesystem, space separated.

Example to apply two security policies to a filesystem named fs0:

weka fs security policy set fs0 fs0allow denyall

Remove all security policies from a filesystem

Command: weka fs security policy reset

Use the following command to remove all security policies from a specified filesystem.

weka fs security policy reset <fs-name>

Parameters

Parameter	Description
fs-name*	Filesystem name.

Attach new security policies to a filesystem

Command: weka fs security policy attach

Use the following command to attach additional security policies to the specified filesystem. If attaching multiple policies, separate each with a space.

weka fs security policy attach <fs-name> [<policies>]...

Parameters

Parameter	Description
fs-name*	Filesystem name.
policies...	Security policy names or IDs to attach new security policies to the specified filesystem, space separated.

Only policies that do not contain roles attributes can be attached to a filesystem. Policies already in use by a tenant or join list cannot be attached to a filesystem.

Detach security policies from a filesystem

Command: weka fs security policy detach

Use the following command to detach (remove) security policies from a filesystem. If detaching multiple policies, separate each with a space.

weka fs security policy detach <fs-name> [<policies>]...

Parameters

Parameter	Description
fs-name*	Filesystem name.
policies...	Security policy names or IDs to remove from the specified filesystem, space separated.

Examples: Implementing CIDR-based security policies

This section provides practical examples of implementing CIDR-based security policies for common use cases.

Example 1: Restrict cluster admin access to backend network

This example demonstrates how to allow only clusteradmin access from a specific backend subnet while denying all other IP addresses.

Scenario: Allow cluster administrators to access the cluster only from the backend network (10.10.0.0/16) and implicitly deny access from all other IP addresses.

1. Create the security policy: Create an allow policy for cluster administrators from the backend subnet:

weka security policy add allow-cluster-admins-backend \
  --action allow \
  --ips 10.10.0.0/16 \
  --roles clusteradmin

1. Attach policy to the root tenant: Attach the policy to the root tenant to enforce it cluster-wide:

weka tenant security policy attach root allow-cluster-admins-backend

Result: Only users with the clusteradmin role connecting from IP addresses within the 10.10.0.0/16 range can access the cluster. All other connections are implicitly denied.

Example 2: Multi-network access control

This example shows how to allow access from multiple networks, such as backend infrastructure and administrative workstations, using a single policy.

Scenario: Allow clusteradmin access from both the backend network (10.10.0.0/16) and administrative workstations (192.168.100.0/24).

1. Create a unified access policy: Instead of creating separate rules, you can provide a comma-separated list to the --ips flag to cover multiple ranges in one go.

weka security policy add allow-admin-networks \
  --action allow \
  --ips 10.10.0.0/16,192.168.100.0/24 \
  --roles clusteradmin

1. Attach both policy: Attach the unified policy to the root tenant:

weka tenant security policy attach root allow-admin-networks

Result: Cluster administrators can now access the cluster from either the backend network or designated admin workstations under a single administrative rule.

Example 3: Read-only filesystem access

This example demonstrates how to provide read-only access to filesystems from specific networks.

Scenario: Allow read-only access to a filesystem from a data analysis network (172.16.0.0/12).

1. Create read-only access policy: Create a policy allowing read-only access from the analysis network:

weka security policy add readonly-analysis-network \
   --action allow \
   --ips 172.16.0.0/12 \
   --read-only true

Filesystem policies cannot include roles. If you need to restrict access by both role and IP range for API authentication, create a separate API authentication policy and attach it to the tenant.

1. Apply policy to specific filesystem: Apply the policy to a specific filesystem (for example, data-warehouse):

weka fs security policy attach data-warehouse readonly-analysis-network

Result: Users have read-only access to the data-warehouse filesystem from the IP range 172.16.0.0/12.

Example 4: Root-squash filesystem access

This example demonstrates how to provide root-squash access to filesystems from specific networks.

Scenario: When a root user accesses a filesystem from a data analysis network (172.16.0.0/12), it will be squashed to uid 1001 and gid 2001.

1. Create root-squash access policy: Create a policy that squashes root uid/gid when accessing from the analysis network:

weka security policy add rootsquash-analysis-network \
   --action allow \
   --ips 172.16.0.0/12 \
   --squash-mode root \
   --anon-uid 1001 \
   --anon-gid 2001

1. Apply policy to specific filesystem: Apply the policy to a specific filesystem (for example, data-warehouse):

weka fs security policy attach data-warehouse rootsquash-analysis-network

Results: The rootsquash-analysis-network policy is applied to the data-warehouse filesystem. Any root user accessing this filesystem from the 172.16.0.0/12 network is automatically squashed to uid 1001 and gid 2001, preventing unrestricted root access. Users from other networks retain their original credentials.

Configure CSI storage classes for root-squashed filesystems

Configure the WEKA CSI plugin to support filesystems where root-squash is enabled. This configuration ensures that the CSI plugin can manage directories and snapshots even when root access is restricted.

Storage class volume types

Definitions for volume types used in CSI configurations:

• dir/v1: A backend type where multiple PVCs reside as directories within a single pre-existing WEKA filesystem.

• weka/v2: A backend type where each PVC corresponds to a dedicated WEKA filesystem or snapshot.

Prerequisites

• A running WEKA cluster.

• WEKA CSI plugin installed on the Kubernetes cluster.

• Administrative access to the WEKA CLI or GUI.

Configure directory-backed storage classes with root-squash

Manage storage classes where the volumeType is set to dir/v1.

1. Create the filesystem in the WEKA cluster.

2. Create a security policy that defines the required anonymous UID and GID.

3. Assign the security policy to the filesystem.

4. Create a directory named csi-volumes manually at the root of the filesystem.

5. Change the ownership of the csi-volumes directory to match the anonymous UID and GID defined in the security policy.

6. Create the Persistent Volume Claim (PVC).

Configure snapshot-backed storage classes with root-squash

Manage storage classes where the volumeType is set to weka/v2 and includes a filesystemName.

1. Create the PVC to trigger the generation of a new filesystem from a snapshot.

2. Create a security policy with the desired root-squash settings using the WEKA CLI.

3. Assign the security policy to the newly created filesystem.

Configure filesystem-backed storage classes with root-squash

Manage storage classes where the volumeType is set to weka/v2 and includes a filesystemGroupName.

1. Create the PVC.

2. Identify the name of the filesystem automatically generated by the CSI plugin.

3. Create a security policy using the WEKA CLI or API.

4. Assign the security policy to the identified filesystem.

Storage class parameter reference

Parameter	Description	Supported values
volumeType	Defines the underlying WEKA storage architecture.	dir/v1, weka/v2
filesystemName	Specifies the source filesystem for snapshot-backed volumes.	Existing filesystem name, to be used with Snapshot Backed or Directory backed PVC
filesystemGroupName	Specifies the group where new filesystems are created.	Existing group name, to be used with Filesystem Backed PVC

Related topic

Storage class configurations (for root-squash configuration with CSI)