Automatisierungentailscaleacl

Ein Tag für alle Arbeitsmaschinen

Christian Drexler

Ein paar Rechner in meinem Tailscale-Netz werden nie von Hand angefasst: ein Mac, der durchläuft und geplante Jobs erledigt, und eine kleine Linux-Kiste, die Dinge baut. Dazu mein Laptop und mein Handy. Die erste Fassung meiner Zugriffsregeln nannte jeden Rechner beim Namen, und jedes Mal, wenn einer dazukam, habe ich drei Stellen bearbeitet und eine davon falsch. Tags lösen das: Ein Rechner trägt ein Etikett, und die Regeln sprechen über das Etikett.

Was ein Tag ist

In Tailscale gehört ein Gerät normalerweise dem Benutzer, der es angemeldet hat. Ein getaggtes Gerät gehört keinem Benutzer; es gehört dem Tag, und das Tag gehört dem, der in der Policy-Datei steht. Zwei Folgen, die mir gefallen. Regeln können sagen "jedes Mitglied darf tag:worker erreichen", ohne Rechner aufzulisten. Und getaggte Geräte haben kein Login, das ablaufen könnte, also trifft sie der 180-Tage-Ablauf nicht, der Rechner ohne Tastatur sonst aussperrt.

Die Policy

Die Policy-Datei ist HuJSON in der Admin-Konsole. Drei Abschnitte zählen:

{
  "tagOwners": { "tag:worker": ["autogroup:admin"] },
  "acls": [
    { "action": "accept", "src": ["autogroup:member"], "dst": ["tag:worker:22,8080"] }
  ],
  "ssh": [
    { "action": "accept", "src": ["autogroup:member"], "dst": ["tag:worker"], "users": ["autogroup:nonroot"] }
  ]
}

tagOwners sagt, dass Admins das Tag vergeben dürfen. Die ACL lässt jedes Mitglied des Netzes (Laptop, Handy) einen Worker auf SSH und einem Web-Port erreichen. Die SSH-Regel lässt mich mit meiner Tailscale-Identität als beliebiges Nicht-Root-Konto auf einem Worker anmelden, ohne Schlüsseldateien. Es gibt keine Regel mit einem Worker als Quelle, also kann ein Worker keine Verbindung zu meinem Laptop oder zu einem anderen Worker öffnen. Eine Einbahnstraße ab Werk, und genau das will ich von einem Rechner, der unbeaufsichtigt läuft.

Einen Rechner taggen

Auf dem Rechner: sudo tailscale up --ssh --advertise-tags=tag:worker, angemeldet mit einem Konto, dem das Tag gehört. Für eine frische Kiste erzeuge ich in der Admin-Konsole einen Auth-Key mit vorausgewähltem Tag und gesetztem "pre-approved"; dann tritt tailscale up --auth-key=... --advertise-tags=tag:worker mit dem richtigen Tag bei, ganz ohne Browser-Login. Das ist das ganze Onboarding für einen neuen Worker: ein Befehl, und die Regeln gelten schon.

Was sich im Alltag geändert hat

Einen Rechner hinzufügen ist keine Policy-Änderung mehr. Mein Handy öffnet die Statusseite eines Workers auf Port 8080, weil das Handy Mitglied ist und die Regel Mitglied zu Worker sagt. tailscale status zeigt getaggte Rechner mit ihrem Tag, ich sehe also auf einen Blick, was Worker ist und was Mensch. Wenn ich einen ausmustere, lösche ich ihn in der Konsole, und nichts sonst verweist auf ihn.

Zwei Fallen

Sobald ein Gerät getaggt ist, passt die Standardregel, die dir SSH auf "deine eigenen" Geräte erlaubt (autogroup:self), nicht mehr darauf, denn es ist nicht mehr deins. Wenn du einen Rechner taggst und SSH danach nicht mehr geht, ist das der Grund; die explizite Tag-Regel oben ist die Lösung. Und --advertise-tags scheitert mit einem Berechtigungsfehler, wenn das angemeldete Konto nicht in tagOwners steht. Die Meldung ist klar genug, aber beim ersten Mal sieht sie aus wie ein Tippfehler im Tag-Namen.

Ab drei Rechnern hat sich das für mich gelohnt. Bei einem ist es Zeremonie; bei einer Handvoll ist es der Unterschied zwischen einer Policy, die du liest, und einer, die du durchsuchst.

tailscaleaclsshtags