DocumentationGroups, resources, and rules
Docs/Groups, resources, and rules

Groups, resources, and access rules

Tunnex rules answer “who may initiate traffic to what destination?” They are allow grants. When enforcement is on, traffic without a matching rule is denied.

Open Access Policies. The top banner shows whether enforcement is Off or Enforcing; the rules inventory can exist in either state.

Rules inventory with enforcement off and attention states

The three sections are:

  • Groups — named sets of people, managed agents, or directory-synced users;
  • Resources — CIDRs or exact FQDN destinations with protocol/port scope; and
  • Rules — one source-to-destination grant, optionally expiring.

Prefer named groups/resources over repeating raw CIDRs. Tunnex can then show empty groups, vanished Kubernetes Services, and destinations outside approved ranges.

  1. Open Access Policies → Groups.
  2. Select Create group.
  3. Choose Group type: People or Managed agents.
  4. Enter Name.
  5. Select Create group.

Group inventory by people, agents, and directory source

Create-group form

Open the group to add members. A directory-synced group is managed through the directory mapping and cannot be edited like a manual group. An empty source group is valid but matches no devices; rules using it show SOURCE GROUP EMPTY.

  1. Open Resources.
  2. Select Create resource.
  3. Select Create CIDR resource.
  4. Enter Name, optional Description, and the exact CIDR.
  5. Choose Protocol.
  6. When TCP or UDP is selected, use the smallest required port/range.
  7. Select Create resource.

CIDR resource inventory with protocol and port scope

CIDR resource creation form

Changing a resource later changes what every referencing rule can reach. Treat resource edits like policy changes, not cosmetic renames.

For exact private hostnames and resolver selection, follow Routed ranges and private DNS.

  1. Return to Rules.
  2. Select Add rule.
  3. In Source, choose a group, person, site, agent, or enter a supported CIDR.
  4. In Destination, choose a group, resource, site, or exposed Kubernetes Service.
  5. Read the generated Access granted sentence. It states the actual effect, not merely the labels you selected.
  6. Optionally enter Expires for a temporary grant.
  7. Select Create.

Add-rule source and destination picker with effect preview

For permanent access, leave expiry empty. For temporary work, prefer an expiring grant or the just-in-time request flow over a standing rule that someone must remember to remove.

StateMeaningFix
OUTSIDE RANGESRaw destination is in no current approved site rangeCorrect the CIDR or approve the intended site range
VANISHEDReferenced Kubernetes Service is no longer exposedRe-expose it or remove/replace the rule
SOURCE GROUP EMPTYSource group has no membersAdd intended members or delete the unused rule
Deactivated personIdentity cannot sign in, but the historical reference remainsReplace/remove the rule after review
Managed by GitOps/templateDashboard is not the source of truthEdit the owning CR/template

Do not enable enforcement with unresolved warnings just because the rule count is nonzero.

Rule editing creates the replacement before removing the old rule. If the second operation fails, Tunnex surfaces the partial state; refresh and inspect both rules rather than retrying blindly.

Deleting a group/resource may cascade into rules or be blocked by immutable references. Read the dependency preview. For directory or GitOps-managed objects, change the upstream owner.

Continue with Test and enforce policy.

Documentation

Search Tunnex docs