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. Passez à l’onglet 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.
Sélectionnez l’onglet Dashboard dans l’interface du laboratoire pour commencer cette étape.
Passez à l’onglet Client et lisez la configuration privée. cat affiche le fichier. Le terminal démarre dans /workspace, son répertoire de configuration :
Passez à l’onglet Client avant d’exécuter la commande suivante.
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. Passez à l’onglet Client et 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.
Sélectionnez l’onglet Client dans l’interface du laboratoire pour commencer cette étape.
Passez à l’onglet Client avant d’exécuter la commande suivante.
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é. Passez à l’onglet Dashboard et actualisez la page, vérifiez que le nom d’utilisateur affiché est 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é.
Si la page affiche WRONGPASS, revenez à l’onglet Client, corrigez les identifiants JSON avec le bloc complet ci-dessus, puis passez à l’onglet Dashboard et réessayez Process ticket. Pour NOPERM, passez à l’onglet Cache Server et exécutez cache-admin ACL GETUSER dashboard pour examiner le motif de clés et les commandes. La commande complète de réinitialisation du premier laboratoire peut réparer un compte mal configuré. Pour un JSON invalide, passez à l’onglet Client et répétez le bloc complet ci-dessus, puis revenez à l’onglet Dashboard pour réessayer.
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 à l’onglet Cache Server. Le compte de maintenance de cache-admin reste actif, préservant l’administration.
Sélectionnez l’onglet Cache Server dans l’interface du laboratoire pour commencer cette étape.
ACL SETUSER default off empêche les nouvelles authentifications avec l’utilisateur par défaut. Enregistrez la modification active dans le fichier ACL configuré :
Passez à l’onglet Cache Server avant d’exécuter la commande suivante.
cache-admin ACL SETUSER default off
cache-admin ACL SAVE
Les deux commandes renvoient OK. Passez à l’onglet Client et tentez une nouvelle connexion sans identifiants :
Passez à l’onglet Client avant d’exécuter la commande suivante.
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.
Passez à l’onglet Dashboard, actualisez la page et cliquez sur Process ticket. Son compte nommé doit continuer à fonctionner. Si vous avez désactivé le mauvais compte, passez à l’onglet Cache Server pour réappliquer sa règle complète correcte, puis enregistrez à nouveau. 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. Passez à l’onglet Client et saisissez Dash-Lab-42 à chaque invite --askpass.
Sélectionnez l’onglet Client dans l’interface du laboratoire pour commencer cette étape.
Passez à l’onglet Client avant d’exécuter la commande suivante.
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. Passez à l’onglet Cache Server et affichez les ACL actives et le fichier enregistré :
Passez à l’onglet Cache Server avant d’exécuter la commande suivante.
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. Passez à l’onglet Dashboard et cliquez une dernière fois sur Process ticket. 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.
