- 07 Oct 2024
-
DarkLight
-
PDF
Shared Token (Redis/Sentinel)
- Updated on 07 Oct 2024
-
DarkLight
-
PDF
One of the requirements of a large scale web application is the ability to utilize load balancers to control user access to the application. A key component of successful high availability is to ensure that users can transfer from one IAP server to another without having to login again. To avoid this, IAP must store all login tokens in a shared location. To facilitate this, our IAP High Availability system utilizes a Redis/Sentinel solution in a Master/Slave configuration to keep tokens available to all IAP servers. This solution also provides failover capabilities between IAP servers in the event a single Redis server should fail.
Note: The following is a living document of information that is continually revised and updated. As such, it may not complement the IAP Installation Guide precisely. We recommend that you check for additional updates and if any questions, please contact Itential Product Support.
Prerequisite Reading:
Please consult the Redis documentation for a full description on installation, configuration, and operation of Redis/Sentinel configuration.
Recommended Configuration
Our recommendation for Shared Token Redis is to use three (3) Redis and three (3) Sentinels. The number of servers recommended is three (3) per data center with a single Redis/Sentinel on each server. This provides the best combination of failover and support.
Example: Basic Master Config
/etc/redis.conf
bind <current server ip> 127.0.0.1
requirepass "<SecretPassword>"
masterauth "<SecretPassword>"
Example: Basic Slave Config
/etc/redis.conf
bind <current server ip> 127.0.0.1
requirepass "<SecretPassword>"
masterauth "<SecretPassword>"
slaveof <master server ip> 6379
Example: Basic Sentinel Config
/etc/redis-sentinel.conf
bind <current server ip> 127.0.0.1
port 26379
sentinel monitor <redis cluster name> <master redis server ip> 6379 2
sentinel down-after-milliseconds <redis cluster name> 10000
sentinel failover-timeout <redis cluster name> 30000
sentinel auth-pass <redis cluster name> "<SecretPassword>"
IAP Specific Configuration
To manage failover Itential recommends the following settings be set on the Redis/Sentinel configuration. The will lower the failover times between Redis servers when the Sentinel detects a Redis is offline. This is done to ensure no delay in the user experience while the failover takes place. The provided values are recommended based on internal test cases.
/etc/redis-sentinel.conf
sentinel down-after-milliseconds mymaster 10000
sentinel failover-timeout mymaster 30000
Security Recommendations
Security characteristics and recommendations for a Shared Token Redis configuration are outlined as follows.
Encryption
Out-of-the box IAP to Redis communications lack the functionality to enable SSL encryption due to a current limitation of the Redis application. Redis is currently working to resolve this issue, and details on this can be found here: Redis Encryption. Because of this limitation, Itential strongly recommends that Shared Token Redis servers have all network access blocked from all outside access other than from IAP servers. The IAP Token should be considered sensitive and confidential information.
TLS is supported by Redis after version 6. However, to build TLS capability into Redis, compile-time flags must be used.
In situations with disaster recovery or a second data center, Itential recommends separate Redis/Sentinel setups each connected to the IAP servers in their data center. This means that IAP servers will only share security tokens with the IAP servers in their data center. Sharing tokens between data centers is not recommended due to the lack of encryption and performance.
Passwords
In addition to network security, Itential recommends that passwords be enabled on Redis servers to help limit access to the token data. The Redis servers, once configured to use a password, will require the password before any access is granted to the tokens stored internally.
Itential recommends installing Redis as described here in Highly Available Redis.