Schlüssel

FortressFlag hat zwei Arten von Schlüsseln, und sie sind absichtlich Gegensätze. Zu wissen, welcher welcher ist — und jeden entsprechend zu behandeln — ist das meiste von dem, was es zu wissen gibt.

Client-Schlüssel: ffc_ — öffentlich by design

Ein Client-Schlüssel authentifiziert die Client-Plane: deine iOS-, Android- und Web-Apps. Er steckt in jeder Kopie deiner App, und jeder mit deinem Binary oder deinem Seitenquelltext kann ihn herauslesen. Das Design geht davon aus. Ein Client-Schlüssel:

• ist nur lesend, beschränkt auf ein Projekt und eine Umgebung
• kann nur die ausgewerteten Werte eines einzelnen Geräts abrufen — nie deine Regeln, nie die Daten eines anderen Geräts, nie irgendetwas aus der Management-API
• ist pro Schlüssel und pro Gerät rate-limited

Leg ihn also mit gutem Gewissen in deine App-Konfiguration. Was jemand erfährt, der deinen Client-Schlüssel besitzt, sind deine Flag-Keys für eine Umgebung — und die konnte er ohnehin schon aus dem Binary lesen, in dem der Schlüssel steckte. Das Präfix ffc_ existiert, damit Secret-Scanner ihn als Client-Schlüssel erkennen und gerade niemanden wecken.

Server-Schlüssel: ffs_ — ein echtes Geheimnis

Ein Server-Schlüssel authentifiziert die Server-Plane: dein eigenes Backend, das das vollständige Ruleset herunterlädt — inklusive Targeting-Regeln — zur lokalen Auswertung. Behandle ihn genau wie ein Datenbankpasswort:

• bewahre ihn in einem Secret-Manager oder einer Umgebungsvariablen auf
• nie in clientseitigem Code, nie in einem Repository, nie in einem Log
• das Präfix ffs_ ist da, damit ein Leak-Scanner ihn als echtes Geheimnis einstuft, das jemanden aus dem Bett holen sollte — das genaue Gegenteil von ffc_, und deshalb teilen die beiden kein Präfix

Auch ein Server-Schlüssel ist auf ein Projekt und eine Umgebung beschränkt, ist nur lesend und kann die Management-API nicht erreichen. Aber sein Schadensradius bei einem Leak sind deine Targeting-Regeln, nicht nur deine Flag-Keys — daher die andere Behandlung.

Erstellen, einmal anzeigen, widerrufen

Schlüssel verwaltest du im Bildschirm SDK-Schlüssel jedes Projekts (Admins und Owners erstellen und widerrufen; Developers können die Liste sehen):

• Erstellen legt einen Schlüssel an, der an ein Projekt + Umgebung gebunden ist. Der vollständige Schlüssel wird genau einmal angezeigt, beim Erstellen — kopiere ihn dann, denn danach zeigt die Liste nur genug, um ihn zu erkennen. Es gibt kein „Schlüssel erneut anzeigen“: Ein Schlüssel, der erneut angezeigt werden kann, ist ein Schlüssel, der in einer Form gespeichert ist, die gestohlen werden kann.
• Widerrufen wirkt ab der nächsten Verwendung des Schlüssels — kein App-Release, kein Deploy. Und es ist sicher, es unter Druck zu tun: SDKs mit einem widerrufenen Schlüssel fallen auf ihren Cache zurück, statt kaputtzugehen.

Rotation

Mehrere aktive Schlüssel pro Umgebung sind erlaubt, und das ist das Rotationsrezept: Erstelle den neuen Schlüssel, roll ihn auf deine Apps oder Server aus, dann widerrufe den alten. Keine Downtime, keine Lücke im Ausliefern von Flags, und das Fenster, in dem beide Schlüssel funktionieren, bestimmst du selbst.

Wie geht es weiter?

• Wie Flags deine App erreichen — die zwei Planes, die diese Schlüssel aufschließen
• Umgebungen und Projekte — der Geltungsbereich, an den ein Schlüssel gebunden ist
• Rollen und Sicherheit — wer erstellen und widerrufen darf