Sleutels

FortressFlag heeft twee soorten sleutels, en ze zijn expres elkaars tegenpolen. Weten welke welke is — en elk dienovereenkomstig behandelen — is het meeste van wat er te weten valt.

Clientsleutels: ffc_ — publiek by design

Een clientsleutel authenticeert het client plane: je iOS-, Android- en webapps. Hij gaat mee in elke kopie van je app, en iedereen met je binary of je paginabron kan hem eruit lezen. Het ontwerp gaat daarvan uit. Een clientsleutel:

• is alleen-lezen, beperkt tot één project en één omgeving
• kan alleen de geëvalueerde waarden van één apparaat ophalen — nooit je regels, nooit de data van een ander apparaat, nooit iets van de management-API
• is rate-limited per sleutel en per apparaat

Zet hem dus met een gerust hart in je appconfiguratie. Wat iemand leert door je clientsleutel te bezitten zijn je flagsleutels voor één omgeving — en die kon hij al uit de binary lezen waar de sleutel in zat. Het voorvoegsel ffc_ bestaat zodat secret scanners hem herkennen als clientsleutel en juist niemand wakker maken.

Serversleutels: ffs_ — een echt geheim

Een serversleutel authenticeert het server plane: je eigen backend die de volledige ruleset downloadt — inclusief targetingregels — voor lokale evaluatie. Behandel hem precies als een databasewachtwoord:

• bewaar hem in een secret manager of een omgevingsvariabele
• nooit in client-side code, nooit in een repository, nooit in een log
• het voorvoegsel ffs_ is er zodat een lekscanner hem classificeert als een echt geheim dat iemand wakker moet piepen — precies het tegenovergestelde van ffc_, en daarom delen de twee geen voorvoegsel

Ook een serversleutel is beperkt tot één project en één omgeving, is alleen-lezen en kan de management-API niet bereiken. Maar zijn schadeoppervlak bij een lek zijn je targetingregels, niet alleen je flagsleutels — vandaar de andere behandeling.

Munten, eenmalig tonen, intrekken

Sleutels beheer je vanuit het SDK-sleutelscherm van elk project (Admins en Owners munten en trekken in; Developers kunnen de lijst bekijken):

• Munten maakt een sleutel aan die aan één project + omgeving is gebonden. De volledige sleutel wordt precies één keer getoond, op het moment van munten — kopieer hem dan, want daarna toont de lijst alleen genoeg om hem te herkennen. Er is geen “toon sleutel opnieuw”: een sleutel die opnieuw getoond kan worden is een sleutel die is opgeslagen in een vorm die gestolen kan worden.
• Intrekken werkt vanaf het volgende gebruik van de sleutel — geen app-release, geen deploy. En het is veilig om onder druk te doen: SDK’s met een ingetrokken sleutel vallen terug op hun cache in plaats van te breken.

Rotatie

Meerdere actieve sleutels per omgeving zijn legaal, en dat is het rotatierecept: munt de nieuwe sleutel, rol hem uit naar je apps of servers, en trek dan de oude in. Geen downtime, geen gat in het serveren van flags, en het venster waarin beide sleutels werken bepaal je zelf.

Waar nu heen?

• Hoe flags je app bereiken — de twee planes die deze sleutels ontsluiten
• Omgevingen en projecten — de scope waar een sleutel aan gebonden is
• Rollen en veiligheid — wie mag munten en intrekken