Clés

FortressFlag a deux sortes de clés, et elles sont opposées à dessein. Savoir laquelle est laquelle — et traiter chacune en conséquence — représente l’essentiel de ce qu’il y a à savoir.

Les clés client : ffc_ — publiques par conception

Une clé client authentifie le plan client : vos apps iOS, Android et web. Elle est embarquée dans chaque copie de votre app, et quiconque a votre binaire ou le code source de votre page peut la lire. Le design part de ce principe. Une clé client :

• est en lecture seule, limitée à un projet et un environnement
• ne peut récupérer que les valeurs évaluées d’un seul appareil — jamais vos règles, jamais les données d’un autre appareil, jamais rien de l’API de gestion
• est limitée en débit par clé et par appareil

Mettez-la donc dans la configuration de votre app la conscience tranquille. Ce que quelqu’un apprend en détenant votre clé client, ce sont vos clés de flags pour un environnement — qu’il pouvait déjà lire dans le binaire d’où venait la clé. Le préfixe ffc_ existe pour que les scanners de secrets la reconnaissent comme une clé client et ne réveillent personne.

Les clés serveur : ffs_ — un vrai secret

Une clé serveur authentifie le plan serveur : votre propre backend qui télécharge le ruleset complet — règles de ciblage incluses — pour une évaluation locale. Traitez-la exactement comme un mot de passe de base de données :

• stockez-la dans un gestionnaire de secrets ou une variable d’environnement
• jamais dans du code côté client, jamais dans un dépôt, jamais dans un journal
• le préfixe ffs_ est là pour qu’un scanner de fuites la classe comme un vrai secret qui doit réveiller quelqu’un — l’exact opposé de ffc_, et c’est pourquoi les deux ne partagent aucun préfixe

Une clé serveur est elle aussi limitée à un projet et un environnement, en lecture seule, et ne peut pas atteindre l’API de gestion. Mais son rayon d’impact en cas de fuite, ce sont vos règles de ciblage, pas seulement vos clés de flags — d’où le traitement différent.

Créer, afficher une fois, révoquer

Les clés se gèrent depuis l’écran Clés SDK de chaque projet (les Admins et les Owners créent et révoquent ; les Developers peuvent voir la liste) :

• Créer produit une clé liée à un projet + un environnement. La clé complète est affichée exactement une fois, au moment de la création — copiez-la à ce moment-là, parce qu’ensuite la liste n’en montre que de quoi l’identifier. Il n’y a pas de « afficher la clé à nouveau » : une clé qui peut être réaffichée est une clé stockée sous une forme qui peut être volée.
• Révoquer prend effet à la prochaine utilisation de la clé — pas de nouvelle version de l’app, pas de déploiement. Et c’est sans danger à faire sous pression : les SDK qui détiennent une clé révoquée retombent sur leur cache plutôt que de casser.

Rotation

Plusieurs clés actives par environnement sont permises, et c’est la recette de la rotation : créez la nouvelle clé, déployez-la vers vos apps ou vos serveurs, puis révoquez l’ancienne. Pas d’interruption, pas de trou dans le service des flags, et la fenêtre pendant laquelle les deux clés fonctionnent est sous votre contrôle.

Où aller ensuite

• Comment les flags arrivent à votre app — les deux plans que ces clés déverrouillent
• Environnements et projets — la portée à laquelle une clé est liée
• Rôles et sécurité — qui peut créer et révoquer