Introduction
Le tableau de bord possède un compte limité préparé, mais se connecte encore avec le compte Redis par défaut, trop large. Vous changerez sa configuration puis retirerez cet ancien accès en préservant le moniteur.
Cet environnement indépendant contient le compte dashboard de la leçon précédente. Les commandes Redis et notions ACL déjà enseignées suffisent. Chaque opération ouvre une nouvelle connexion et utilise donc la configuration actuelle.
Établir le fonctionnement initial de l’application
Dans cette étape, vous établirez le fonctionnement normal de ce nouvel environnement. Ouvrez Dashboard. L’entrée est Ticket 104: password reset, le résultat est vide et l’utilisateur est default. Cliquez sur Process ticket et retrouvez Processed: Ticket 104: password reset.
Dans Client, lisez la configuration privée. cat affiche le fichier. Le terminal démarre dans /workspace, son répertoire de configuration :
cat app.json
JSON conserve des champs nommés entre accolades. username identifie l’utilisateur Redis et password fournit son secret d’authentification. Les chaînes sont entre guillemets doubles et les champs séparés par des virgules. Actuellement, l’utilisateur est default et le mot de passe est vide.
L’application relit le fichier à chaque requête et ouvre de nouvelles connexions Redis. Aucun redémarrage ni code client n’est nécessaire. Un compte monitor distinct lit monitor:heartbeat : préservez-le en modifiant le compte par défaut. Le fichier contient des secrets ; il est privé et n’est pas servi publiquement.
Basculer la connexion du tableau de bord
Dans cette étape, vous ferez utiliser le compte limité à l’application. Dans Client, remplacez la configuration à deux champs. cat > app.json redirige le texte suivant vers le fichier et remplace son contenu. EOF entre apostrophes démarre un document intégré : collez toutes les lignes, y compris le EOF final seul sur sa ligne. Les apostrophes empêchent l’expansion du shell dans le JSON.
cat > app.json <<'EOF'
{"username":"dashboard","password":"Dash-Lab-42"}
EOF
Seule la configuration change. Le compte possède déjà GET/SET sous support:* dans ce nouvel instantané. Rechargez Dashboard, vérifiez dashboard, puis cliquez à nouveau sur Process ticket. Un ancien résultat ne suffit pas : cette nouvelle opération prouve la lecture et l’écriture avec le compte configuré.
Pour WRONGPASS, corrigez les identifiants JSON puis réessayez. Pour NOPERM, utilisez cache-admin ACL GETUSER dashboard dans Cache Server pour examiner motif et commandes. La commande complète de réinitialisation du premier laboratoire répare un compte mal configuré. Répétez le bloc précédent pour corriger un JSON invalide.
N’utilisez pas maint comme raccourci : l’application doit avoir son propre compte limité.
Retirer l’entrée par défaut trop large
Dans cette étape, vous désactiverez l’accès automatique sans désactiver les comptes légitimes. Passez à Cache Server. Le compte de maintenance de cache-admin reste actif, préservant l’administration.
ACL SETUSER default off empêche les nouvelles authentifications avec l’utilisateur par défaut. Enregistrez la modification active dans le fichier ACL configuré :
cache-admin ACL SETUSER default off
cache-admin ACL SAVE
Les deux commandes renvoient OK. Passez à Client et tentez une nouvelle connexion sans identifiants :
redis-cli -h cache-server GET support:ticket
Attendez NOAUTH Authentication required., le refus souhaité. Il diffère de NOPERM, qui signale un manque de droits pour un compte authentifié. Chaque appel crée une connexion. Désactiver un utilisateur ne garantit pas la fermeture des sessions déjà authentifiées ; leur révocation sort de cet exercice.
Rechargez Dashboard et cliquez sur Process ticket. Son compte nommé doit fonctionner. Si vous avez désactivé le mauvais compte, réappliquez sa règle complète correcte depuis le terminal de maintenance puis enregistrez. Ne réactivez pas le compte par défaut trop large pour masquer une erreur de configuration applicative.
Tester ensemble sécurité et disponibilité
Dans cette étape, vous comparerez opérations autorisées, données interdites et commande inutile. Utilisez Client et saisissez Dash-Lab-42 à chaque invite --askpass.
redis-cli -h cache-server --user dashboard --askpass GET support:result
Le résultat de support reste lisible. La commande suivante demande volontairement des données financières étrangères :
redis-cli -h cache-server --user dashboard --askpass GET finance:payroll
Attendez NOPERM. CONFIG GET lit les paramètres du serveur ; même cette lecture administrative est inutile ici. L’étoile entre apostrophes demande tous les noms et doit parvenir telle quelle à Redis :
redis-cli -h cache-server --user dashboard --askpass CONFIG GET '*'
Attendez un NOPERM lié à la commande. Utilisez ensuite l’identité du moniteur existant, avec Monitor-Lab-42 au prompt :
redis-cli -h cache-server --user monitor --askpass GET monitor:heartbeat
Attendez healthy. Désactiver tous les comptes ou arrêter Redis ferait échouer ce test positif et ne constitue pas une réparation. Dans Cache Server, affichez les ACL actives et le fichier enregistré :
cache-admin ACL LIST
cat /data/users.acl
Les entrées enregistrées doivent correspondre aux actives, y compris default off. Sinon, répétez cache-admin ACL SAVE. Terminez par Process ticket dans Dashboard. Disponibilité réelle et refus pertinents établissent le résultat ; une page saine seule ne prouve pas le moindre privilège.
Résumé
Vous avez basculé la véritable application vers un compte Redis limité, désactivé les nouvelles connexions par défaut, enregistré les ACL et testé requêtes interdites ainsi que fonctionnement métier et moniteur. Les tests utilisent de nouvelles connexions et ne prouvent pas la révocation des sessions existantes.
