ACL: some documentation inside redis.conf.
This commit is contained in:
parent
80f987726d
commit
af8761e4f2
88
redis.conf
88
redis.conf
@ -501,6 +501,94 @@ replica-priority 100
|
||||
# can be easily a long string from /dev/urandom or whatever, so by using a
|
||||
# long and unguessable password no brute force attack will be possible.
|
||||
|
||||
# Redis ACL users are defined in the following format:
|
||||
#
|
||||
# user <username> ... acl rules ...
|
||||
#
|
||||
# For example:
|
||||
#
|
||||
# user worker +@list +@connection ~jobs:* on >ffa9203c493aa99
|
||||
#
|
||||
# The special username "default" is used for new connections. If this user
|
||||
# has the "nopass" rule, then new connections will be immediately authenticated
|
||||
# as the "default" user without the need of any password provided via the
|
||||
# AUTH command. Otherwise if the "default" user is not flagged with "nopass"
|
||||
# the connections will start in not authenticated state, and will require
|
||||
# AUTH (or the HELLO command AUTH option) in order to be authenticated and
|
||||
# start to work.
|
||||
#
|
||||
# The ACL rules that describe what an user can do are the following:
|
||||
#
|
||||
# on Enable the user: it is possible to authenticate as this user.
|
||||
# off Disable the user: it's no longer possible to authenticate
|
||||
# with this user, however the already authenticated connections
|
||||
# will still work.
|
||||
# +<command> Allow the execution of that command
|
||||
# -<command> Disallow the execution of that command
|
||||
# +@<category> Allow the execution of all the commands in such category
|
||||
# with valid categories are like @admin, @set, @sortedset, ...
|
||||
# and so forth, see the full list in the server.c file where
|
||||
# the Redis command table is described and defined.
|
||||
# The special category @all means all the commands, but currently
|
||||
# present in the server, and that will be loaded in the future
|
||||
# via modules.
|
||||
# +<command>|subcommand Allow a specific subcommand of an otherwise
|
||||
# disabled command. Note that this form is not
|
||||
# allowed as negative like -DEBUG|SEGFAULT, but
|
||||
# only additive starting with "+".
|
||||
# allcommands Alias for +@all. Note that it implies the ability to execute
|
||||
# all the future commands loaded via the modules system.
|
||||
# nocommands Alias for -@all.
|
||||
# ~<pattern> Add a pattern of keys that can be mentioned as part of
|
||||
# commands. For instance ~* allows all the keys. The pattern
|
||||
# is a glob-style pattern like the one of KEYS.
|
||||
# It is possible to specify multiple patterns.
|
||||
# allkeys Alias for ~*
|
||||
# resetkeys Flush the list of allowed keys patterns.
|
||||
# ><password> Add this passowrd to the list of valid password for the user.
|
||||
# For example >mypass will add "mypass" to the list.
|
||||
# This directive clears the "nopass" flag (see later).
|
||||
# <<password> Remove this password from the list of valid passwords.
|
||||
# nopass All the set passwords of the user are removed, and the user
|
||||
# is flagged as requiring no password: it means that every
|
||||
# password will work against this user. If this directive is
|
||||
# used for the default user, every new connection will be
|
||||
# immediately authenticated with the default user without
|
||||
# any explicit AUTH command required. Note that the "resetpass"
|
||||
# directive will clear this condition.
|
||||
# resetpass Flush the list of allowed passwords. Moreover removes the
|
||||
# "nopass" status. After "resetpass" the user has no associated
|
||||
# passwords and there is no way to authenticate without adding
|
||||
# some password (or setting it as "nopass" later).
|
||||
# reset Performs the following actions: resetpass, resetkeys, off,
|
||||
# -@all. The user returns to the same state it has immediately
|
||||
# after its creation.
|
||||
#
|
||||
# ACL rules can be specified in any order: for instance you can start with
|
||||
# passwords, then flags, or key patterns. However note that the additive
|
||||
# and subtractive rules will CHANGE MEANING depending on the ordering.
|
||||
# For instance see the following example:
|
||||
#
|
||||
# user alice on +@all -DEBUG ~* >somepassword
|
||||
#
|
||||
# This will allow "alice" to use all the commands with the exception of the
|
||||
# DEBUG command, since +@all added all the commands to the set of the commands
|
||||
# alice can use, and later DEBUG was removed. However if we invert the order
|
||||
# of two ACL rules the result will be different:
|
||||
#
|
||||
# user alice on -DEBUG +@all ~* >somepassword
|
||||
#
|
||||
# Now DEBUG was removed when alice had yet no commands in the set of allowed
|
||||
# commands, later all the commands are added, so the user will be able to
|
||||
# execute everything.
|
||||
#
|
||||
# Basically ACL rules are processed left-to-right.
|
||||
#
|
||||
# For more information about ACL configuration please refer to
|
||||
# the Redis web site at https://redis.io/topics/acl
|
||||
|
||||
# Using an external ACL file
|
||||
#
|
||||
# Instead of configuring users here in this file, it is possible to use
|
||||
# a stand-alone file just listing users. The two methods cannot be mixed:
|
||||
# if you configure users here and at the same time you activate the exteranl
|
||||
|
Loading…
Reference in New Issue
Block a user