Understand the Dashboard's Cache Access

RedisBeginner
Practice Now

Introduction

A support dashboard uses Redis to cache a ticket and its processed result. You will keep that workflow working while creating an account limited to its own data.

Redis stores values under names called keys. A cache key is a data name, not a password. This lab uses synthetic tickets and a real Redis server in an isolated training network. Basic terminal use is enough; no Redis or programming experience is required. The Client and Cache Server tabs enter separate containers sharing this instance's kernel. Dashboard displays real requests, not a security score.

Process a Support Ticket

In this step, you will establish what the application normally does. Redis is a server: it holds named values and answers requests. The dashboard is a client: it asks Redis for a ticket, processes it, and writes a result. A cache is a convenient store used by an application; these training values are synthetic. The input is stored at support:ticket; the processed output is stored at support:result.

Open Dashboard. The page shows input and result. Initially, the input is Ticket 104: password reset and the result is empty. Click Process ticket once. The result becomes Processed: Ticket 104: password reset. Reloading reads the stored value again. This is a real read followed by a write.

The page also shows username: default. A username identifies the Redis account; it is separate from a cache key. The app currently uses the automatically available default account without a password. Working business output establishes availability, but says nothing about which other data that account can reach.

If the page shows a connection error, reload once. Do not treat an error page as a permission denial. Leave both terminal tabs open; use their names to keep track of where you are.

Compare Useful Access with Excess Access

In this step, you will read and write a disposable value, then see why the default access is too broad. Use Client. The prepared terminal is inside the application container. redis-cli is Redis's command-line client. -h cache-server selects the server by its private network name; localhost here would mean the client container itself.

GET reads a key. Read the dashboard input:

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

The response contains Ticket 104: password reset. The colon is simply part of the key name. The support: prefix groups this application's data.

SET writes a value. Use demo:note, a disposable practice key, so the dashboard's business input stays intact:

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

OK means the write succeeded. Read it back:

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

The response is practice. Now read an unrelated synthetic finance value:

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

You receive Private payroll: synthetic. The support dashboard has no business reason to read payroll. Authentication answers who connects; authorization decides which commands and keys they may use. The default account currently permits both this unrelated read and unnecessary administrative commands.

Create a Bounded Application Account

In this step, you will give a named account only the operations and key family it needs. Switch to Cache Server. cache-admin is a prepared helper that runs the real redis-cli using the separate maintenance account. It is for administration, not application configuration.

An access control list (ACL) gives each account command and key rules. The dashboard needs GET and SET under support:*. The star means any suffix after support:; this simple prefix pattern is not a regular expression.

ACL SETUSER creates or changes an account. reset clears previous rules, on enables authentication, >... supplies its password, ~... supplies its key pattern, and +get +set permits exactly those commands. Single quotes protect > and * from the shell. Without them the shell could redirect output or expand filenames. Run:

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

Expect OK. The password Dash-Lab-42 authenticates an account; it is not a Redis data key. Training credentials are local examples, not production secrets.

Switch to Client. --user selects the named account, --askpass prompts without including the password in the command line. Type Dash-Lab-42 at each password prompt (characters may be hidden):

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

The ticket is still readable. Test the unrelated key with another new connection:

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

Expect NOPERM: authentication succeeded, but the key is forbidden. WRONGPASS means the username/password is wrong; correct it and retry. A connection error means the service cannot be reached and is not a successful restriction. If you mistyped the ACL, repeat the complete reset command in Cache Server with the correct values.

Save the Active ACL

In this step, you will persist the account so its permissions survive a future service start. An in-memory ACL change takes effect immediately, but it does not automatically update the configured file. Use Cache Server:

cache-admin ACL SAVE

Expect OK. Redis writes its active users to /data/users.acl, the ACL file used by this server. cat displays a file; inspect the saved rules:

cat /data/users.acl

The dashboard line contains ~support:*, -@all, +get, and +set (order can vary). -@all means all command categories start denied. A value beginning with # is Redis's password hash, not the original password.

Compare the active account using:

cache-admin ACL GETUSER dashboard

Look for the same key family and command permissions. Editing an unused file would not change the running account. ACL SAVE persists the actual active rules.

The default entry remains enabled in this lab. Creating a better account does not switch existing applications or retire the old path. The next lab starts with its own independent snapshot and teaches those remaining changes. Never put the maintenance credentials into the application.

Summary

You processed a real support ticket, distinguished data keys from passwords, compared legitimate and excessive access, and created and persisted a named account limited to GET/SET under support:*. The old default path still needs to be retired after the application switches.