Skip to content

Model CRS310 Tailscale sidecar tags and subnet routes in Dhall ACL #11

Description

@Jesssullivan

Context

CRS310 has a RouterOS-hosted Tailscale sidecar. The crs repo currently tracks live drift in tinyland-inc/crs310-8g-2s-in issue #45, and the sidecar runtime work is being tracked in the MikroTik sidecar repo.

The tailnet ACL repo should own the policy-level decision about which tags, subnet routes, and capabilities the CRS310 sidecar is allowed to use.

Problem

The 2026-04-24 audit found drift between live sidecar behavior and repo intent:

  • advertised route set was stale,
  • route acceptance/import behavior did not match intended posture,
  • auth material needs rotation after live RouterOS env readback exposed it to operators.

Without a Dhall-side contract, the sidecar can become an unreviewed route/import path instead of a controlled subnet-router component.

Proposed Work

  • Model CRS310 sidecar identity/tags in Dhall.
  • Define the allowed subnet route set for CRS310 sidecar advertisement.
  • Define whether route approval should be automatic or manual.
  • Explicitly model whether CRS310 may accept/import remote subnet routes; current crs intent is that it should not import them by default.
  • Add generated policy/test coverage that makes CRS310 route/tag drift visible before deployment.
  • Link this issue to the sidecar runtime issues and crs issue #45.

Acceptance

  • Dhall policy has a named CRS310 sidecar entry or reusable typed fragment.
  • Generated ACL output includes the intended tags/routes/grants for CRS310.
  • Tests fail if CRS310 route advertisement or route-import posture drifts.
  • crs issue #45 can reference this repo as the ACL source of truth.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions