Docs

Configure team and organisation security policies

Team and organization security policies apply access rules to multiple services. A policy can require authentication, restrict access, or remove security controls for HTTP paths on every matching service.

Single sign-on (SSO) uses the login provider for your organization.

Use these policies to:

  • Require SSO for administrative paths across several teams
  • Restrict internal tools to approved IP addresses
  • Require Basic Auth or a request header for a group of services
  • Define an organization default that teams can replace where permitted
  • Exclude resources from a specific policy

Policies apply to every public HTTP and HTTP/2 port on matching deployment and combined services. You cannot select individual ports. These policies do not change port exposure or apply to private-only ports or other protocols.

You need permission to read security policies to view them. You need the corresponding create, update, or delete permission to manage them. If the security policies page or an expected team is unavailable, contact your Northflank administrator or support.

How security policies apply

Northflank evaluates team and organization security policies by path. With Path and descendants, / matches every path and /admin matches only /admin and its child paths.

For each request path, Northflank determines the applicable policy at each level:

  1. Northflank selects the highest-priority matching organization policy.
  2. Northflank selects the highest-priority matching team policy.
  3. The winning organization policy determines whether a team policy can replace it, as shown below.
  4. If neither level has a matching policy, Northflank uses the service access configuration.
Winning organization policyMatching team policyResult
EnforcedYes or noOrganization policy
DefaultYesTeam policy
DefaultNoOrganization policy
NoneYesTeam policy
NoneNoService access configuration

Northflank compares priorities within each level. It does not compare a team priority numerically with an organization priority.

A more specific path does not automatically win. At the same level, a higher-priority policy for / can replace a policy for /admin when both use Path and descendants.

Each winning policy supplies the complete access configuration for its matching path. Northflank does not combine its controls with controls from another policy or the service. Paths outside its scope use other matching policies or the service access configuration.

The Enforced mode prevents a team policy from replacing the winning organization policy. It does not remove internal-traffic exceptions.

Create a team security policy

New policies start disabled. Enabled policies in the same team must have unique priorities. A higher value wins when multiple team policies match the same path.

To create and enable a team security policy:

  1. Open the team and select CloudSecurity policies.
  2. Select Create security policy.
  3. Enter a name and optional description.
  4. Enter a priority.
  5. Configure the paths, access mode, targets, exclusions, and security controls.
  6. Select Create policy to save a disabled policy.
  7. On the saved policy, select Preview.
  8. Review the matching services and their access rules.
  9. Select Enable.
  10. Review the policy status as Northflank applies the change.

You can also preview the draft before creation. This preview does not replace the preview on the saved policy.

Team policies can target all or selected projects and services within those projects. You can also filter services by workload tags. See targets and exclusions.

Create an organisation security policy

New policies start disabled. Enabled policies in the same organization must have unique priorities. A higher value wins when multiple organization policies match the same path.

The Team inheritance mode determines whether a team policy can replace the winning organization policy. Enforced prevents replacement, while Default allows a matching team policy to replace it.

A default can replace an enforced policy

Before enabling an organization default, review its effect on enforced policies. A higher-priority organization default can replace a lower-priority enforced policy. This can let a team policy replace those access rules. Northflank requires acknowledgment of any displayed inheritance warning before activation or an enabled policy update.

To create and enable an organization security policy:

  1. Open the organization and select CloudSecurity policies.
  2. Select Create security policy.
  3. Enter a name, optional description, and priority.
  4. Select a Team inheritance mode.
  5. Configure the paths, access mode, targets, exclusions, and security controls.
  6. Select Create policy to save a disabled policy.
  7. On the saved policy, select Preview.
  8. Review the result by team, project, service, port, and path.
  9. If an inheritance warning appears, review and acknowledge it.
  10. Select Enable.
  11. Review the policy status as Northflank applies the change.

You can also preview the draft before creation. This preview does not replace the preview on the saved policy.

An organization policy can target eligible teams, projects within those teams, and services with matching workload tags. Organization policies cannot directly select or exclude individual services. See organization targets.

Configure paths and access

Add paths

Every policy must include at least one path. All paths in one policy share the same access mode, targets, exclusions, priority, and security controls. Create another policy when a path needs a different result.

Choose a match mode for each path.

The Exact path mode matches only the configured path. /admin does not match /admin/users.

The Path and descendants mode also matches child paths. /admin matches /admin and /admin/users, but not /administrator.

Use / with Path and descendants to apply the policy to every path. Paths are case-sensitive and must begin with /. Paths cannot contain query strings, fragments, or repeated slashes. Team and organization policies do not support regular expressions.

Northflank removes a trailing slash from configured paths, except /. For example, Northflank saves /admin/ as /admin for an Exact path match.

Choose an access mode

The Protected mode evaluates the security controls you add. With no controls, it denies external requests but allows requests through project-internal addresses. See internal traffic.

The Unprotected (public) mode allows requests without security controls when the policy wins for a path. It replaces existing protection for that path, but does not expose a private port.

Before enabling an unprotected policy, review the preview for changes that remove protection.

Add security controls

CIDR notation describes a range of IP addresses. For protected access, select Add security control.

The available controls are:

  • IP addresses: allow or deny addresses and CIDR ranges
  • Request headers: require a header name and matching value
  • Basic Auth: require a username and password
  • SSO: require an organization user or selected directory groups

SSO is available when your organization configures it.

Place each control in Required or Optional. Every required control must pass. If you configure optional controls, at least one must also pass.

For example, use a required IP rule with optional SSO and Basic Auth controls. An external request must match the IP rule and pass either SSO or Basic Auth. A single optional control is effectively required. IP deny rules can only be required.

Internal traffic

The winning enforced organization policy determines which access rules apply. It does not remove existing exceptions for internal traffic.

Requests through public endpoints normally use security controls, even when they originate inside the project.

Requests through project-internal addresses bypass IP and request-header controls. Basic Auth can still apply.

Require SSO for internal requests

To require SSO for project-internal requests, place SSO in Required. Then enable Validate internal traffic. By default, a policy that includes SSO bypasses all controls for these requests, including Basic Auth. See use an SSO provider.

Services can also apply internal-traffic exceptions to requests through their Northflank HTTPS hostnames. This covers requests from the same project or projects with ingress permission. Team and organization policies preserve this service configuration. See allow internal traffic to skip security policies.

These exceptions concern internal requests to ports marked public. Team and organization policies do not apply to private-only ports.

Policy limits

The following limits apply:

ConfigurationLimit
Paths configured in one policy50
Enabled policies in one team or organization100
Combined path entries for one service port200
Configuration for one policy256 KiB
Combined access configuration for one service port, before compression256 KiB

Northflank rejects a policy that exceeds the individual size limit when you save it.

Matching policies and service access rules contribute to the combined limits. One configured path can produce multiple entries in the combined rules.

If the combined rules exceed the path-count or size limit, Northflank blocks external requests to the affected port and reports an error. It does not apply a partial configuration. To restore access, reduce overlapping paths or simplify the policy configuration.

Select targets and exclusions

Targets define where a policy can apply. Exclusions remove specific resources from those targets.

Team targets

A team policy can target:

  • All projects or selected projects
  • All services in the project scope or selected deployment and combined services
  • Services that match one or all configured workload tags

Each service must match the configured project and service selections. If tag filtering is enabled, the service must also match any or all selected tags, as configured.

You can exclude projects and individual services from a team policy.

Organization targets

An organization policy can target:

  • All eligible teams or selected teams
  • All projects in the team scope or selected team/project pairs
  • Services that match one or all configured workload tags

Each service must belong to the selected team and project scope. If tag filtering is enabled, the service must also match any or all selected tags, as configured. Organization tag names match workloads directly in each selected team. Organization policies cannot directly select or exclude individual services. You can exclude teams and projects.

To create a service exception to an organization default, create a team policy that selects the service.

For an exception to an enforced policy, create a higher-priority organization policy with the required access rules. Target it by a dedicated workload tag or project. Alternatively, exclude the entire project or team from the enforced policy.

How exclusions behave

An exclusion removes only the policy that contains it. Another matching policy can still apply to the excluded resource. For example, an excluded project can still use another organization policy, a team policy, or service access rules.

Preview and manage policies

Preview a policy

Select Preview before enabling a policy or saving changes to an enabled policy. Preview uses your unsaved form values and does not save or apply them.

If you change the form after a preview, select Preview again. For organization policies, acknowledge any displayed inheritance warning. Saving a disabled policy does not require a preview or acknowledgment.

The preview shows:

  • Matching and excluded services
  • The resulting access for each public HTTP or HTTP/2 port and path
  • Whether the proposed policy applies or another policy takes precedence
  • The organization, team, or service rule that supplies the resulting access
  • Priority conflicts and changes that remove existing protection
  • Organization inheritance warnings and paths where team policies replace organization defaults

Previews can show a sample of services or split results across pages. Organization previews can span multiple teams and projects.

Preview evaluates the configured paths. It does not inspect application endpoints or live enforcement, guarantee successful application, or predict exactly when changes take effect.

Understand policy status

  • Disabled: Northflank stores the policy but does not enforce it.
  • Applying: Northflank is applying an enabled policy.
  • Active: Northflank applied the enabled policy to its matching services.
  • Failed: Northflank cannot apply or remove the policy on every affected service. Northflank retries automatically.
  • Removing: Northflank is removing the effect of a disabled or deleted policy from services.
  • Removal failed: Northflank cannot finish removing the policy from services during deletion. Northflank retries automatically. If this status persists, contact support.

Northflank applies policy updates in the background without restarting workloads. Changes to targets or workload tags can take time to appear in policy status and service access rules.

Disable or delete a policy

To stop applying a policy but keep it for later use, select Disable. Northflank removes its effect from services in the background.

Deleting a policy also starts removal in the background. During deletion, the policy remains visible and read-only until Northflank removes its effect from services. Northflank then removes the policy from the list.

If the status is Removing or Removal failed, the policy can still affect service access.

Examples and best practices

Protect an administrative path across a team

Create a team policy with:

  • Path /admin using Path and descendants
  • Access mode Protected
  • SSO as a required control
  • The projects or workload tags used by your administrative services

This policy applies where no enforced organization policy or higher-priority team policy takes precedence. Other paths use another matching policy or the service access configuration. For SSO on internal requests, review the internal-traffic configuration.

Set an organization default with a team exception

Create these policies with Path and descendants for both paths:

LevelPathTeam inheritanceAccess modeRequired control
Organization/DefaultProtectedIP allow rule
Team/adminNot applicableProtectedSSO

When these policies win at their respective levels, /admin and its child paths use the team policy. The team policy replaces the IP rule with SSO. Other paths use the organization default unless another policy takes precedence. If multiple team policies match /admin, the highest team priority wins.

Enforce SSO without allowing team overrides

Create an organization policy for /admin with Path and descendants, Enforced inheritance, Protected access, and required SSO.

If this policy has the highest matching organization priority, team policies cannot replace it. A higher-priority organization default can still permit team replacement. Enforced inheritance does not remove internal-traffic exceptions.

Keep static assets public

Create both policies in the same team or organization:

PathMatch modeAccess modePriority
/Path and descendantsProtected, with your chosen controls50
/assetsPath and descendantsUnprotected (public)100

If other policies use these priorities, choose unused values that keep the /assets policy higher. Northflank evaluates priority before path specificity within each level. A higher-priority policy or organization inheritance can still change the result. Review the preview before enabling these policies.

Best practices

  • Before enabling a saved policy, preview its affected services and access rules.
  • Use meaningful names that describe scope and purpose, such as admin-sso or office-ip-baseline.
  • Keep policies focused. Put paths with different access results in separate policies.
  • Assign priorities deliberately and leave gaps between values to make future ordering changes easier.
  • Review unprotected policies and organization defaults for changes that remove protection.
  • Use exclusions for explicit exceptions. Another policy can still apply afterward.
  • Test policy changes on a small project or selected services before broadening their target scope.

© 2026 Northflank Ltd. All rights reserved.

northflank.com / Terms / Privacy / feedback@northflank.com