Label-scoped access policies that take precedence over resource rules (incident kill switch)

[strausmann]

Summary

Allow an organization admin to bind an access policy to a label selector instead of to individual resources. All resources whose effective labels match the selector are restricted immediately, with precedence over their own rules, and the restriction is never touched by blueprint sync. Effects: block (403), maintenance page with a policy-defined message and ETA, or put Pangolin SSO in front for selected users/roles.

Motivation

This idea came directly out of PHP2Shell (CVE-2026-109618 / CVE-2026-109619), the PHP remote-code-execution vulnerabilities published in October 2026. I run several PHP applications behind Pangolin, all of them managed through Docker-label blueprints. When the advisory came out, I wanted to take every affected application off the public internet immediately — without stopping the containers and without editing and redeploying each stack while waiting for patched images.

I couldn't do that with Pangolin today:

• Pausing a resource doesn't stick: if a blueprint doesn't set enabled, the next sync sets it back to true within seconds (server/lib/blueprints/publicResources.ts).
• Assigning a shared resource policy doesn't stick either: without policy in the blueprint, sync writes resourcePolicyId: null.
• Resource policies (1.19) solved reusable rule sets (Ability to define "rule groups" and use them to apply to resources #3497), but they are attached per resource. There is no way to say "apply this to everything labelled platform::php".

So in the end I had to stop the services themselves or touch every affected stack — slow, error-prone, and exactly when time mattered most. Several open requests point the same way: #1563 (global rules), #2317 (org-level access control), #298 (disable a resource on demand).

Proposed Solution

A label policy binding at organization level:

• Name and reason (e.g. "CVE-XXXX-YYYY") — shown in the audit log and optionally on the block/maintenance page.

• Selector on effective labels (see Scoped labels (`scope::value`) that survive blueprint sync, plus label inheritance from sites #3978), conditions combined with AND. Each condition has an origin (resource:, site: or *: for either), a scope, and a value matcher:

  Matcher	Example
  one or more values (UI offers existing values as a dropdown)	resource:platform ∈ {php, perl}
  wildcard	resource:platform_version = 8.4.*
  range (dot-separated numeric comparison, so 8.4.9 < 8.4.27)	resource:platform_version >= 8.4.0 and < 8.4.27
  scope exists	resource:platform
  plain label	legacy
  either origin	*:location = dc-a

• Values are stored as text, not as references to label rows. If no resource carries a value anymore, the selector keeps it (the UI marks it as "manually entered, currently no match"). An emergency block must not dissolve silently while a container is being rebuilt and briefly has no labels.

• Rules: same format and engine as today's resource rules (ACCEPT / DROP / PASS by CIDR, IP, COUNTRY, COUNTRY_IS_NOT, ASN, REGION, PATH, METHOD, with priority), plus a default action.

• Effect when a request is not let through:

  • Block: 403.
  • Maintenance page: reuse the existing maintenance page with title, message and estimated time defined in the policy (same fields as today's maintenance mode; same tier as the maintenance page). If the policy has an expiry, it is offered as the default ETA.
  • Require SSO: put Pangolin SSO in front of the matched resources for selected users/roles — even if the resource normally runs without Pangolin SSO because the app has its own login. After SSO, the app's own login still applies. This keeps a service usable for your own people during an incident while removing anonymous internet access. Non-browser clients (sync clients, mobile apps, WebDAV) can't do SSO; a policy ACCEPT rule (e.g. your VPN's CIDR) can exempt them.

• Enabled toggle and optional expiry (auto-disable or reminder).

• Evaluation order: matching label policies are evaluated before the resource's own rules, by priority. DROP triggers the effect regardless of the resource's rules, auth and SSO settings. PASS hands over to the resource's own rules. ACCEPT only skips this layer — the resource's own auth still applies. A label policy can only restrict access, never weaken a resource's protection. If several policies with different effects match, the strictest wins (block > maintenance > require SSO).

• Not part of blueprints: label policies are created and changed only via UI/API. Blueprint sync never creates, changes or removes them. The blueprint only provides labels, which the selector uses. That keeps blueprints authoritative for what they define (compatible with Visual indicator and protection of resources created by docker labels #1860) and puts the incident layer on top.

• Visibility: a live preview "affects N resources" (recomputed, since labels change), and a banner on each affected resource "restricted by policy X (effect)".

Scope: public resources. Private/site resources are out of scope for a first step.

Performance. Every request to a public HTTP resource already goes through Badger, which calls POST /badger/verify-session; verifySession.ts already runs checkRules() per request, backed by localCache (resource and rules for 5 s, country/ASN for 5 min). I'd add the label-policy step in the same place, before checkRules(), using the same cache pattern (labelPolicies:<resourceId>):

• The selector is resolved per resource, not per request: which bindings apply to resource X (own + inherited labels, wildcards, ranges) is computed when the cache entry is empty and then reused. Per request only the rule evaluation remains — the same kind of work as today.
• Country and ASN are already looked up for the existing rules, so there is no extra lookup.
• Activating, changing or disabling a policy invalidates the affected cache entries, so a block takes effect immediately instead of after the cache TTL.
• I'd deliberately not translate policies into Traefik rules: Traefik itself can only match IPs (ipAllowList), not country, ASN, maintenance page or SSO; Badger calls Pangolin on every request anyway, so there's nothing to gain; and two places evaluating rules would make the feature harder to reason about and test.

Alternatives Considered

• Admin lock per resource that sync can't override, plus bulk action by label — smaller, but only on/off; can't express "only from these networks/countries" or "SSO for my own users only".
• Only fixing Blueprint overwriting non configured settings #2197 (sync touches only fields it sets) — necessary, but not an incident tool: you'd still edit every resource one by one.
• Org-wide global rules ([Feature Request] Global rules #1563) — close, but applies to everything; incidents usually concern a subset (one platform, one version range, one location).

Additional Context

Questions for the maintainers:

1. Would you rather see this as an extension of resource policies (a policy gets an optional label selector) or as a separate object?
2. Free or paid tier? (The maintenance-page effect would follow the existing maintenance tier.)
3. Is putting SSO in front of resources that intentionally run without Pangolin SSO acceptable, and how should the UI signal the double login?

Offer to contribute: I'm willing to implement this myself once the direction, shape and tier are agreed — as a series of small PRs against dev (data model + API, request-path evaluation, UI, effects), starting with the label-origin change from #3978. If it helps, I'm glad to coordinate in a Discord chat as well.

Depends on / related: #3978 (scoped labels, origin, inheritance), #3980 (auto-detection), #1563, #2317, #3497, #298, #2197, #1860.

AI disclosure: this request was drafted with the help of an AI assistant (Claude Code), based on reading the current dev source; I reviewed and edited it. Any PR would disclose AI use in the PR template as required.

[strausmann]

One addition after thinking through the lifecycle with automatically updated labels (see my comment in #3980):

If labels are refreshed by a scanner, a resource can drop out of a policy on its own — for example when a patched image no longer has the CVE label. Whether that should automatically lift the restriction is a security decision, because a wrong or missing label would silently reopen the resource. I'd propose a setting per policy:

• Auto-release — a resource is restricted only while it matches the selector. Convenient when labels come from a trusted scanner.
• Sticky until released — once a resource has matched, it stays restricted until someone releases it explicitly (per resource, with the release recorded in the audit log). The UI would show these resources as "no longer matching — awaiting release".

Default: sticky. In an incident, I'd rather release patched apps one by one than have a scanner hiccup reopen something.

AI disclosure: drafted with the help of an AI assistant (Claude Code); reviewed and edited by me.