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

-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 organizations 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 organization. For non-root organizations, only the OrgAdmin 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 organization or filesystem, always include a final policy that denies access to all other IPs after attaching the necessary policies.

  • Policy capacity:

    • 16 policies can be assigned per organization.

    • 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 using the CLI

Add and manage security policies so that you can apply them on the organization 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]...

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, orgadmin, 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)

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]
[--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)

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. (format: clusteradmin, orgadmin, regular, readonly or s3, may be repeated or comma-separated)

In this example a policy is created 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]...

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, orgadmin, regular, readonly or s3, may be repeated or comma-separated)

--add-roles...

User roles to append to the security policy. (format: clusteradmin, orgadmin, regular, readonly or s3, may be repeated or comma-separated)

--remove-roles...

User roles to remove from the security policy. (format: clusteradmin, orgadmin, 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)

In this example the readonly role is added to an existing security policy called admin_network:

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, orgadmin, 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.

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 proces

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 organization security policies using the CLI

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

  • List security policies for a specified organization.

  • Set security policies for a specified organization.

  • Remove all security policies from a specified organization.

  • Attach new security policies to a specified organization.

  • Detach security policies from a specified organization.

List the organization security policies

Command: weka org security policy list

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

weka org security policy list <org>

The command weka org also displays the attached policies for each organization.

Parameters

Parameter
Description

org*

Organization name or ID.

Set security policies for an organization

Command: weka org security policy set

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

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

Parameters

Parameter
Description

org*

Organization name or ID.

policies...

Security policy names or IDs to assign to the organization, space separated.

Remove all security policies from an organization

Command: weka org security policy reset

Use the following command to removes all security policies from an organization.

weka org security policy reset <org>

Parameters

Parameter
Description

org*

Organization name or ID.

Attach new security policies to an organization

Command: weka org security policy attach

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

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

Parameters

Parameter
Description

org*

Organization name or ID.

policies...

Security policy names or IDs to attach to the organization, space separated.

Detach security policies from an organization

Command: weka org security policy detach

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

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

Parameters

Parameter
Description

org*

Organization name or ID.

policies...

Security policy names or IDs to remove from the organization, space separated.

Manage filesystem security policies using the CLI

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.

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 organization: Attach the policy to the root organization to enforce it cluster-wide:

weka 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.

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 policy for backend access:

weka security policy add allow-backend-admins \
  --action allow \
  --ips 10.10.0.0/16 \
  --roles clusteradmin
  1. Create a policy for admin workstation access:

weka security policy add allow-admin-workstations \
  --action allow \  
  --ips 192.168.100.0/24 \
  --roles clusteradmin
  1. Attach both policies: Attach both policies to the root organization:

weka org security policy attach root allow-backend-admins allow-admin-workstations

Result: Cluster administrators can access the cluster from either the backend network or designated admin workstations.

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) while maintaining full access control for other roles.

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

weka security policy add readonly-analysis-network \
   --action allow \
   --ips 172.16.0.0/12 \
   --roles readonly
  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 with the readonly role can access the "data-warehouse" filesystem from the analysis network for read-only operations.

Last updated