Comprender el acceso a la caché del panel

RedisBeginner
Practicar Ahora

Introducción

Un panel de soporte usa Redis para almacenar en caché un ticket y su resultado procesado. Mantendrás el flujo operativo mientras creas una cuenta limitada a sus propios datos.

Redis almacena valores bajo nombres llamados claves. Una clave de caché es un nombre de datos, no una contraseña. Este laboratorio usa tickets sintéticos y un servidor Redis real en una red de formación aislada. Basta con el uso básico de la terminal; no requiere Redis ni programación. Client y Cache Server abren contenedores separados que comparten el núcleo de esta instancia. Dashboard muestra solicitudes reales, no una puntuación de seguridad.

Procesar un ticket de soporte

En este paso, establecerás el funcionamiento normal de la aplicación. Redis es el servidor: guarda valores con nombre y responde a solicitudes. El panel es un cliente: pide un ticket, lo procesa y escribe un resultado. Una caché es un almacén práctico para una aplicación; estos valores son sintéticos. La entrada se guarda en support:ticket y la salida procesada en support:result.

Abre Dashboard. La página muestra input y result. Al principio, la entrada es Ticket 104: password reset y el resultado está vacío. Haz clic una vez en Process ticket. Aparece Processed: Ticket 104: password reset. Recargar vuelve a leer el valor almacenado. Es una lectura seguida de una escritura reales.

También aparece username: default. El nombre de usuario identifica la cuenta Redis, no una clave de caché. La aplicación usa ahora la cuenta predeterminada disponible automáticamente, sin contraseña. El resultado de negocio demuestra disponibilidad, pero no indica qué otros datos puede alcanzar esa cuenta.

Si aparece un error de conexión, recarga una vez. Una página de error no equivale a una denegación de permisos. Mantén ambas pestañas de terminal abiertas y usa sus nombres para identificar dónde trabajas.

Comparar el acceso útil con el excesivo

En este paso, leerás y escribirás un valor desechable y verás por qué el acceso predeterminado es demasiado amplio. Usa Client, cuya terminal preparada está en el contenedor de la aplicación. redis-cli es el cliente de línea de comandos de Redis. -h cache-server selecciona el servidor por su nombre de red privada; aquí localhost señalaría el propio contenedor cliente.

GET lee una clave. Lee la entrada del panel:

redis-cli -h cache-server GET support:ticket

La respuesta contiene Ticket 104: password reset. Los dos puntos forman parte del nombre. El prefijo support: agrupa los datos de esta aplicación.

SET escribe un valor. Usa demo:note, una clave desechable de práctica, para conservar la entrada de negocio:

redis-cli -h cache-server SET demo:note practice

OK significa que se escribió correctamente. Léela:

redis-cli -h cache-server GET demo:note

La respuesta es practice. Ahora lee un valor financiero sintético ajeno:

redis-cli -h cache-server GET finance:payroll

Recibes Private payroll: synthetic. El panel no tiene motivo de negocio para leer nóminas. La autenticación determina quién conecta; la autorización decide qué comandos y claves puede usar. La cuenta predeterminada permite esta lectura ajena y comandos administrativos innecesarios.

Crear una cuenta de aplicación limitada

En este paso, darás a una cuenta identificada solo las operaciones y la familia de claves necesarias. Cambia a Cache Server. cache-admin es un ayudante preparado que ejecuta el redis-cli real con una cuenta de mantenimiento separada. Sirve para administrar, no para configurar la identidad de la aplicación.

Una lista de control de acceso (ACL) asigna reglas de comandos y claves a cada cuenta. El panel necesita GET y SET sobre support:*. El asterisco representa cualquier sufijo después de support:; este patrón sencillo no es una expresión regular.

ACL SETUSER crea o modifica una cuenta. reset borra reglas anteriores, on habilita autenticación, >... fija la contraseña, ~... el patrón y +get +set permite solo esos comandos. Las comillas simples protegen > y * del shell; sin ellas podría redirigir salida o expandir nombres de archivo. Ejecuta:

cache-admin ACL SETUSER dashboard reset on '>Dash-Lab-42' '~support:*' +get +set

Espera OK. Dash-Lab-42 autentica una cuenta; no es una clave de datos Redis. Estas credenciales son ejemplos locales de formación, no secretos de producción.

Vuelve a Client. --user elige la cuenta y --askpass solicita la contraseña sin incluirla en la línea de comandos. Escribe Dash-Lab-42 en cada solicitud; los caracteres pueden ocultarse:

redis-cli -h cache-server --user dashboard --askpass GET support:ticket

El ticket sigue siendo legible. Prueba la clave ajena con otra conexión nueva:

redis-cli -h cache-server --user dashboard --askpass GET finance:payroll

Espera NOPERM: la autenticación funcionó, pero la clave está prohibida. WRONGPASS indica usuario o contraseña incorrectos; corrígelos y repite. Un error de conexión indica un servicio inaccesible, no una restricción correcta. Si escribiste mal la ACL, repite el comando completo con reset y los valores correctos en Cache Server.

Guardar la ACL activa

En este paso, persistirás la cuenta para conservar sus permisos en un futuro arranque. Los cambios en memoria surten efecto inmediatamente, pero no actualizan automáticamente el archivo configurado. Usa Cache Server:

cache-admin ACL SAVE

Espera OK. Redis escribe los usuarios activos en /data/users.acl, el archivo ACL usado por este servidor. cat muestra un archivo; revisa las reglas guardadas:

cat /data/users.acl

La línea de dashboard contiene ~support:*, -@all, +get y +set; el orden puede variar. -@all parte de denegar todas las categorías de comandos. Un valor que empieza por # es el hash Redis de la contraseña, no la contraseña original.

Compara la cuenta activa:

cache-admin ACL GETUSER dashboard

Busca la misma familia de claves y los mismos permisos. Editar un archivo no utilizado no cambiaría la cuenta en ejecución. ACL SAVE persiste las reglas realmente activas.

La entrada predeterminada permanece habilitada en este laboratorio. Crear una cuenta mejor no cambia las aplicaciones existentes ni retira la vía anterior. El próximo laboratorio parte de una instantánea independiente y enseña esos cambios. Nunca pongas las credenciales de mantenimiento en la aplicación.

Resumen

Procesaste un ticket real, distinguiste claves de datos de contraseñas, comparaste acceso legítimo y excesivo, y creaste y guardaste una cuenta limitada a GET/SET sobre support:*. La vía predeterminada anterior aún debe retirarse después de cambiar la aplicación.