Connect to Redis with ACL users and TLS
To use a Redis ACL user, enter the user name in Username and its password in Password. To use TLS, turn on Use TLS with certificate verification. DevOpsPad then authenticates with AUTH <username> <password> and verifies the server certificate against the host name you entered.
For these setups, and whenever an SSH tunnel is on, DevOpsPad uses the upstream go-redis client directly. The eredis component used for plain connections does not forward named ACL users and can drop a verified TLS configuration, so DevOpsPad avoids it in those cases. You do not need to change anything; this explains why TLS and ACL behave correctly.
ACL users
| Username field | What is sent |
|---|---|
| Empty | AUTH <password> if a password is set |
default |
The default user, same as a password-only server |
| Any other name | AUTH <username> <password> |
A read-only ACL user is the safest account for DevOpsPad. This rule allows only the commands DevOpsPad’s editor and Explorer use, on every key:
ACL SETUSER devopspad on >change-me ~* resetchannels -@all +ping +info +dbsize +type +ttl +pttl +get +mget +getrange +hget +hlen +hscan +lrange +llen +scard +sscan +zcard +zscan +xrange +scan
Restrict ~* to key patterns such as ~session:* if the user should only see part of the keyspace. Run ACL SETUSER from an admin session, not from DevOpsPad, which does not allow ACL.
TLS
- Edit the connection and turn on Use TLS with certificate verification.
- Use the TLS port of your server or managed service. Many providers use a port other than
6379; check their console. - Enter the host name that appears in the server certificate. An IP address only works if the certificate includes it.
- Click Test connection.
DevOpsPad requires TLS 1.2 or later. Certificates are verified against the operating system’s trust store.
TLS through an SSH tunnel
When both an SSH tunnel and TLS are on, DevOpsPad opens the TCP connection through SSH and then performs the TLS handshake over it, verifying the certificate for the host name in the connection. If the Redis host is 127.0.0.1 and the certificate names redis.internal, verification fails. Use a host name that the SSH server can resolve and that matches the certificate.
Limits
- Custom CA certificates and client certificates (mutual TLS) are not configurable yet. Servers signed by a private CA that your OS does not trust cannot be verified.
- Redis Cluster and Sentinel are not supported.
Frequently asked questions
Does DevOpsPad verify the Redis TLS certificate?
Yes. With TLS turned on, DevOpsPad requires TLS 1.2 or later and verifies the certificate against the system trust store and the host name in the connection.