[GH-ISSUE #6673] Feature Request: Add reverse-proxy access control flags to netbird expose #11617

Open
opened 2026-08-05 01:30:11 -04:00 by saavagebueno · 3 comments
Owner

Originally created by @constantins2001 on GitHub (Jul 6, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/6673

Problem

The NetBird dashboard supports Access Control Rules for reverse-proxy services. In the service editor, the Access Control tab allows rules that allow or block traffic based on:

  • Country
  • IP address
  • CIDR block

The current netbird expose CLI help exposes authentication-related options such as password, PIN, and SSO user groups, but it does not expose the same access-control rule model:

netbird expose <port> [flags]

Flags:
      --protocol string
      --with-custom-domain string
      --with-external-port uint16
      --with-name-prefix string
      --with-password string
      --with-pin string
      --with-user-groups strings

This means services created from the CLI cannot be made equivalent to services created or edited in the dashboard when IP/CIDR/country filtering is required.

Why this matters

netbird expose is the natural workflow for temporary services, local development, CI/test environments, and scripted automation. Those are often exactly the cases where an operator wants a tight allowlist, for example only allowing requests from a known set of public IPs or CIDR ranges.

Without CLI support, users must either:

  • create the exposed service with netbird expose, then manually edit it in the dashboard
  • leave the service exposed more broadly than intended
  • avoid the CLI for automation and use manual dashboard configuration instead

That breaks the otherwise useful imperative workflow of netbird expose.

Proposed solution

Add flags to netbird expose that map to the existing reverse-proxy access-control rule model.

One possible shape:

# Allow only specific source IPs
netbird expose 8080 \
  --protocol https \
  --allow-ip 35.231.147.226 \
  --allow-ip 35.243.134.228

# Allow a CIDR and block a country
netbird expose 8080 \
  --allow-cidr 203.0.113.0/24 \
  --block-country RU

# L4 example
netbird expose 5432 \
  --protocol tcp \
  --with-external-port 5433 \
  --allow-cidr 198.51.100.0/24

Suggested flags:

--allow-ip strings
--block-ip strings
--allow-cidr strings
--block-cidr strings
--allow-country strings
--block-country strings

Alternatively, a single repeatable structured flag could work if that fits the existing parser/API model better, for example:

--access-rule allow:ip:35.231.147.226
--access-rule allow:cidr:203.0.113.0/24
--access-rule block:country:RU

Expected behavior

  • Services created with netbird expose can carry the same Access Control Rules as services configured in the dashboard.
  • The CLI should preserve the dashboard semantics, including block rules taking priority over allow rules.
  • Omitting the new flags should preserve the current behavior.
  • Validation should match the dashboard/API validation for IP addresses, CIDR blocks, and country codes.

This is related to existing reverse-proxy access-control requests, but is narrower: it asks for CLI parity with the dashboard's existing Access Control Rules surface.

Originally created by @constantins2001 on GitHub (Jul 6, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/6673 ## Problem The NetBird dashboard supports Access Control Rules for reverse-proxy services. In the service editor, the Access Control tab allows rules that allow or block traffic based on: - Country - IP address - CIDR block The current `netbird expose` CLI help exposes authentication-related options such as password, PIN, and SSO user groups, but it does not expose the same access-control rule model: ```text netbird expose <port> [flags] Flags: --protocol string --with-custom-domain string --with-external-port uint16 --with-name-prefix string --with-password string --with-pin string --with-user-groups strings ``` This means services created from the CLI cannot be made equivalent to services created or edited in the dashboard when IP/CIDR/country filtering is required. ## Why this matters `netbird expose` is the natural workflow for temporary services, local development, CI/test environments, and scripted automation. Those are often exactly the cases where an operator wants a tight allowlist, for example only allowing requests from a known set of public IPs or CIDR ranges. Without CLI support, users must either: - create the exposed service with `netbird expose`, then manually edit it in the dashboard - leave the service exposed more broadly than intended - avoid the CLI for automation and use manual dashboard configuration instead That breaks the otherwise useful imperative workflow of `netbird expose`. ## Proposed solution Add flags to `netbird expose` that map to the existing reverse-proxy access-control rule model. One possible shape: ```bash # Allow only specific source IPs netbird expose 8080 \ --protocol https \ --allow-ip 35.231.147.226 \ --allow-ip 35.243.134.228 # Allow a CIDR and block a country netbird expose 8080 \ --allow-cidr 203.0.113.0/24 \ --block-country RU # L4 example netbird expose 5432 \ --protocol tcp \ --with-external-port 5433 \ --allow-cidr 198.51.100.0/24 ``` Suggested flags: ```text --allow-ip strings --block-ip strings --allow-cidr strings --block-cidr strings --allow-country strings --block-country strings ``` Alternatively, a single repeatable structured flag could work if that fits the existing parser/API model better, for example: ```text --access-rule allow:ip:35.231.147.226 --access-rule allow:cidr:203.0.113.0/24 --access-rule block:country:RU ``` ## Expected behavior - Services created with `netbird expose` can carry the same Access Control Rules as services configured in the dashboard. - The CLI should preserve the dashboard semantics, including block rules taking priority over allow rules. - Omitting the new flags should preserve the current behavior. - Validation should match the dashboard/API validation for IP addresses, CIDR blocks, and country codes. ## Related issues This is related to existing reverse-proxy access-control requests, but is narrower: it asks for CLI parity with the dashboard's existing Access Control Rules surface. - #5539 - #5861 - #5862 - #6052
Author
Owner

@linear-code[bot] commented on GitHub (Jul 6, 2026):

NET-1354

<!-- gh-comment-id:4891283862 --> @linear-code[bot] commented on GitHub (Jul 6, 2026): <!-- linear-linkback --> <p><a href="https://linear.app/netbird/issue/NET-1354">NET-1354</a></p>
Author
Owner

@jnfrati commented on GitHub (Jul 6, 2026):

Hey @constantins2001 although we appreciate the innitiative, we do have a process for contributors:

  1. Did you created a discussion first that backs this issue as stated by our issues lifecycle?
  2. Did you had a chat with someone from the team before opening a PR as stated by contributing guidelines?
<!-- gh-comment-id:4891926878 --> @jnfrati commented on GitHub (Jul 6, 2026): Hey @constantins2001 although we appreciate the innitiative, we do have a process for contributors: 1. Did you created a discussion first that backs this issue as stated by [our issues lifecycle](https://github.com/netbirdio/netbird/discussions/6075)? 2. Did you had a chat with someone from the team before opening a PR as [stated by contributing guidelines](https://github.com/netbirdio/netbird/blob/main/CONTRIBUTING.md#discuss-changes-with-the-netbird-team-first)?
Author
Owner

@constantins2001 commented on GitHub (Jul 6, 2026):

Thanks for pointing that out. I missed the discussion-first flow before opening the issue/PR.

I created a discussion for validation here: https://github.com/netbirdio/netbird/discussions/6676

I did not have a prior chat with the NetBird team before opening the PR, so I converted https://github.com/netbirdio/netbird/pull/6675 back to draft while the direction/scope is validated. Happy to adjust, pause, or close the PR depending on the outcome of the discussion.

<!-- gh-comment-id:4892130859 --> @constantins2001 commented on GitHub (Jul 6, 2026): Thanks for pointing that out. I missed the discussion-first flow before opening the issue/PR. I created a discussion for validation here: https://github.com/netbirdio/netbird/discussions/6676 I did not have a prior chat with the NetBird team before opening the PR, so I converted https://github.com/netbirdio/netbird/pull/6675 back to draft while the direction/scope is validated. Happy to adjust, pause, or close the PR depending on the outcome of the discussion.
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#11617