RedisCLI icon
Docker icon
If icon
Fail icon
OutputValues icon
Log icon
SlackIncomingWebhook icon
Loop icon
Schedule icon

Redis ACL User Audit

Find Redis ACL users with nopass, +@all or dangerous commands, every-key access or unknown names, alert Slack, fix with ACL SETUSER and verify.

Categories
DataInfrastructure

Redis 6 added ACLs, and many deployments now have a dozen users, some of them risky:

  • a worker created with nopass during a test;
  • a legacy service account with +@all that can FLUSHALL production;
  • a debugging user allowed KEYS and DEBUG;
  • the default user still open to anyone who can reach the port.

ACL LIST shows all of it, but nobody reads it.

This blueprint reads ACL LIST with redis-cli, checks every enabled user against a few rules, and alerts Slack. It can disable passwordless users and remove dangerous commands with ACL SETUSER, then read ACL LIST again to verify. Password hashes are stripped before anything is logged or sent.

This blueprint was created by zkasuran.

Findings

Finding Severity Rule Fix
NOPASS High Enabled user with nopass ACL SETUSER <user> off. Never applied to default: reported with the advice to set a password
DANGEROUS_COMMANDS High +@all, +@dangerous, +@admin, or an explicit FLUSHALL, CONFIG, KEYS, DEBUG, SHUTDOWN, ACL, MODULE... outside the admin users -@dangerous for +@all, otherwise removes each listed command
ALL_KEYS Medium ~* outside the admin users Report only
UNKNOWN_USER Medium Not in known_users or admin_users Report only

Fixes only add rules to the user, so the rest of its ACL is kept.

How it works

  1. acl_list (io.kestra.plugin.redis.cli.RedisCLI, read-only) runs ACL LIST.
  2. readable fails the run when no user line came back, for example a NOPERM reply. An audit that saw nothing must not read as clean.
  3. findings parses the users and applies the rules in one jq program, stored in vars.rules and reused for the verification. summary logs every finding.
  4. route (io.kestra.plugin.core.flow.If):
    • clean: logs it.
    • findings: alert posts to Slack.
      • remediate_gate runs only when auto_remediate is true and dry_run is false.
      • remediate (io.kestra.plugin.core.flow.Loop) runs one ACL SETUSER per fix, each in its own RedisCLI task.
      • acl_relist and after apply the same rules to a fresh ACL LIST. verify_result fails if a fixed finding is still there.
  5. errors alerts Slack when the audit cannot run.

ACL changes live in memory. The final log reminds you to run ACL SAVE when the server uses an aclfile, or to update its configuration.

What you get

  • A daily review of every Redis user, with the reason each finding matters.
  • Fixes that restrict users without rewriting their ACL, behind two gates, verified by a second ACL LIST.
  • No false clean result when the auditing user is not allowed to list ACLs.

Who it's for

  • Platform teams running Redis for many services with ACL users.
  • Security teams that need evidence that passwordless and over-privileged accounts are removed.
  • Teams evaluating the Redis plugin who want an example of RedisCLI driving an audit and its fixes.

Why orchestrate this with Kestra

ACL LIST answers the question for one instance at one moment. Kestra runs it on a schedule, keeps the list of known and admin users next to the flow, turns findings into a Slack alert, applies fixes only behind auto_remediate and dry_run, and keeps a history that shows when a risky user appeared and when it was fixed.

Tested end to end

On Kestra 2.0.5 OSS against Redis 7, with a local HTTP sink standing in for Slack. Users seeded with ACL SETUSER:

  • app, restricted;
  • cache-worker with nopass;
  • legacy with +@all ~*;
  • tmp-debug with +keys +debug;
  • ops-admin (admin), and the open default user.
Run Inputs Result
1 defaults 10 findings across cache-worker, default, legacy and tmp-debug. app and ops-admin not flagged. Alert sent
2 auto_remediate: true, dry_run: true Same report. ACL GETUSER cache-worker still on nopass
3 auto_remediate: true, dry_run: false cache-worker off, legacy -@dangerous, tmp-debug -keys -debug. Verified by the second ACL LIST. Then in Redis: AUTH cache-worker gets WRONGPASS, FLUSHALL as legacy and KEYS as tmp-debug get NOPERM, and app still reads and writes
4 a server where the connecting user cannot run ACL LIST Fails with the NOPERM reply instead of reporting 0 findings
5 a server with only a restricted default and a known app Only the 2 findings on default
6 unknown host errors alert sent

Prerequisites

  • Redis 6 or later, reachable from the Docker containers the RedisCLI tasks start.
  • The connecting user needs acl|list, and acl|setuser for remediation.
  • For a password or a named user, add password: "{{ secret('REDIS_PASSWORD') }}" and username to each RedisCLI task.
  • Local testing: docker run -d --name redis -p 6379:6379 redis:7-alpine, then create users with ACL SETUSER.

Secrets

  • SLACK_WEBHOOK_URL: used by alert and the errors block. In Kestra OSS, provide it as the base64-encoded environment variable SECRET_SLACK_WEBHOOK_URL.

Inputs

Input Default Purpose
host / port localhost / 6379 Redis instance
known_users [app, cache-worker] Expected application users
admin_users [ops-admin] Users allowed every command and key
network empty Docker network for the redis-cli containers
auto_remediate false Allow ACL SETUSER
dry_run true Must be false for a change to apply

Quick start

  1. Add the SLACK_WEBHOOK_URL secret.
  2. Import the flow and set host, known_users, admin_users and, if Redis runs in Docker, network.
  3. Run it once and read the findings.
  4. Check which clients use a flagged user, then run with auto_remediate: true and dry_run: false, and save the ACLs.
  5. Enable the daily trigger, which always runs in safe mode.

How to extend

  • Run ACL SAVE after verify_result when your servers use an aclfile.
  • Loop over a list of hosts to audit every instance in one execution.
  • Add a rule for users with access to every Pub/Sub channel (&*).
  • Read ACL LOG to report denied commands after a fix, so a broken client is found quickly.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.