Introduction
Un tableau de bord utilise Redis pour mettre en cache un ticket et son résultat traité. Vous conserverez ce fonctionnement tout en créant un compte limité à ses propres données.
Redis stocke des valeurs sous des noms appelés clés. Une clé de cache est un nom de donnée, pas un mot de passe. Ce laboratoire utilise des tickets synthétiques et un véritable serveur Redis dans un réseau isolé. Les bases du terminal suffisent, sans expérience Redis ni programmation. Client et Cache Server ouvrent des conteneurs distincts partageant le noyau de cette instance. Dashboard affiche de vraies requêtes, pas un score de sécurité.
Traiter un ticket de support
Dans cette étape, vous établirez le fonctionnement normal de l’application. Redis est le serveur : il conserve des valeurs nommées et répond aux requêtes. Le tableau de bord est un client : il demande un ticket à Redis, le traite et écrit un résultat. Un cache est un stockage pratique pour une application ; les valeurs de formation sont synthétiques. L’entrée est stockée sous support:ticket et le résultat traité sous support:result.
Ouvrez Dashboard. La page affiche input et result. Au départ, l’entrée est Ticket 104: password reset et le résultat est vide. Cliquez une fois sur Process ticket. Le résultat devient Processed: Ticket 104: password reset. Recharger lit de nouveau la valeur stockée. Il s’agit d’une vraie lecture suivie d’une écriture.
La page affiche aussi username: default. Le nom d’utilisateur identifie le compte Redis, indépendamment d’une clé de cache. L’application utilise actuellement le compte par défaut, disponible automatiquement sans mot de passe. Un résultat métier valide prouve la disponibilité, mais ne dit rien des autres données accessibles au compte.
Si la page affiche une erreur de connexion, rechargez une fois. Une page d’erreur n’est pas un refus d’autorisation. Gardez les deux onglets de terminal ouverts et repérez votre emplacement grâce à leur nom.
Comparer les accès utiles et excessifs
Dans cette étape, vous lirez et écrirez une valeur jetable, puis comprendrez pourquoi l’accès par défaut est trop large. Utilisez Client. Le terminal préparé se trouve dans le conteneur de l’application. redis-cli est le client Redis en ligne de commande. -h cache-server choisit le serveur par son nom réseau privé ; ici, localhost désignerait le conteneur client lui-même.
GET lit une clé. Lisez l’entrée du tableau de bord :
redis-cli -h cache-server GET support:ticket
La réponse contient Ticket 104: password reset. Les deux-points font simplement partie du nom de clé. Le préfixe support: regroupe les données de l’application.
SET écrit une valeur. Utilisez demo:note, une clé de pratique jetable, pour préserver l’entrée métier :
redis-cli -h cache-server SET demo:note practice
OK signifie que l’écriture a réussi. Relisez-la :
redis-cli -h cache-server GET demo:note
La réponse est practice. Lisez maintenant une valeur financière synthétique sans rapport :
redis-cli -h cache-server GET finance:payroll
Vous obtenez Private payroll: synthetic. Le tableau de bord n’a aucune raison métier de lire la paie. L’authentification détermine qui se connecte ; l’autorisation détermine les commandes et clés utilisables. Le compte par défaut permet cette lecture étrangère ainsi que des commandes d’administration inutiles.
Créer un compte applicatif limité
Dans cette étape, vous accorderez à un compte nommé uniquement les opérations et la famille de clés nécessaires. Passez à Cache Server. cache-admin est un assistant préparé qui lance le vrai redis-cli avec le compte de maintenance distinct. Il sert à l’administration, pas à configurer l’identité de l’application.
Une liste de contrôle d’accès (ACL) définit les commandes et clés autorisées pour chaque compte. Le tableau de bord a besoin de GET et SET sous support:*. L’étoile signifie tout suffixe après support: ; ce simple motif de préfixe n’est pas une expression régulière.
ACL SETUSER crée ou modifie un compte. reset efface les anciennes règles, on active l’authentification, >... fournit le mot de passe, ~... le motif de clés et +get +set autorise uniquement ces commandes. Les apostrophes protègent > et * du shell, qui pourrait sinon rediriger la sortie ou développer des noms de fichiers. Exécutez :
cache-admin ACL SETUSER dashboard reset on '>Dash-Lab-42' '~support:*' +get +set
Attendez OK. Dash-Lab-42 authentifie un compte, ce n’est pas une clé de donnée Redis. Ces identifiants de formation sont des exemples locaux, pas des secrets de production.
Passez à Client. --user sélectionne le compte et --askpass demande le mot de passe sans l’inscrire dans la commande. À chaque invite, saisissez Dash-Lab-42 ; les caractères peuvent être masqués :
redis-cli -h cache-server --user dashboard --askpass GET support:ticket
Le ticket reste lisible. Testez la clé étrangère avec une autre nouvelle connexion :
redis-cli -h cache-server --user dashboard --askpass GET finance:payroll
Attendez NOPERM : l’authentification a réussi mais la clé est interdite. WRONGPASS signale un nom ou mot de passe incorrect ; corrigez et réessayez. Une erreur de connexion indique un service inaccessible, pas une restriction réussie. En cas de faute dans l’ACL, répétez la commande complète avec reset et les bonnes valeurs dans Cache Server.
Enregistrer l’ACL active
Dans cette étape, vous rendrez le compte persistant pour conserver ses droits lors d’un prochain démarrage. Un changement d’ACL en mémoire prend effet immédiatement sans mettre automatiquement à jour le fichier configuré. Utilisez Cache Server :
cache-admin ACL SAVE
Attendez OK. Redis écrit les utilisateurs actifs dans /data/users.acl, le fichier ACL utilisé par ce serveur. cat affiche un fichier ; examinez les règles enregistrées :
cat /data/users.acl
La ligne dashboard contient ~support:*, -@all, +get et +set, dans un ordre variable. -@all refuse initialement toutes les catégories de commandes. Une valeur commençant par # est le hachage Redis du mot de passe, pas le mot de passe original.
Comparez avec le compte actif :
cache-admin ACL GETUSER dashboard
Retrouvez la même famille de clés et les mêmes droits. Modifier un fichier inutilisé ne changerait pas le compte en cours d’exécution. ACL SAVE conserve les règles réellement actives.
L’entrée par défaut reste activée dans ce laboratoire. Créer un meilleur compte ne bascule pas les applications existantes et ne retire pas l’ancien accès. Le prochain laboratoire utilise un instantané indépendant et enseigne ces modifications. Ne placez jamais les identifiants de maintenance dans l’application.
Résumé
Vous avez traité un vrai ticket, distingué clés de données et mots de passe, comparé accès légitimes et excessifs, puis créé et enregistré un compte limité à GET/SET sous support:*. L’ancien accès par défaut reste à retirer après la bascule de l’application.
