Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

Elasticache Redis IAM auth token refresh

0

We have an Elasticache replication group setup in a private VPC with Redis engine 5.0.6 and in our service we use a long-lived JedisPool connection to connect to the cache. We are trying to enable access control to this cache using RBAC-IAM Auth.

After enabling access control, for the client connections to work we need to provide either an auth token or credentials in the request. And since we are using JedisPool which doesn't have support for the credentials provider we are planning to send an auth token signed using AWS sigV4 pre-signed request as suggested in the documentation here.

Since IAM auth token is valid only for 15 mins but the JedisPool is long-lived, we had to implement a background scheduler that refreshes the token before it expires and creates a new pool with latest token and gracefully close out the old pool to avoid resource exhaustion.

Questions:

  1. Is this the right way to refresh token and re-create pools, do you have any suggestions?
  2. Do you recommend any specific time to refresh the token e.g every 5 mins or 7 mins?
  3. Do you recommend to migrate us to use a Redis client that support credential provider and takes care of the refresh logic?
  4. Is there anything that we missing to consider when we are doing this auth token refresh?
  5. Is there any other mechanism that we can use instead of the background scheduler?
Topics
Security, Identity, & ComplianceDatabase
Tags
Amazon ElastiCacheAWS Identity and Access ManagementAmazon ElastiCache for Redis
Language
English
asked a year ago675 views
2 Answers
3

How about this:

  1. Is this the right way to refresh token and re-create pools, do you have any suggestions? Implementing a background scheduler to refresh the authentication token and recreate the JedisPool is a practical solution, considering the limitations of JedisPool in supporting a credentials provider. However, this approach inherently adds operational complexity and may lead to increased overhead from frequent pool re-creation.

  2. Do you recommend any specific time to refresh the token e.g every 5 mins or 7 mins? Refreshing the token at an interval of 5 to 7 minutes is a prudent strategy, as it guarantees the token remains valid while incorporating a buffer to account for potential delays. The specific interval should be determined based on the application's tolerance for downtime and the frequency with which the token is utilized.

  3. Do you recommend to migrate us to use a Redis client that support credential provider and takes care of the refresh logic? Transitioning to a Redis client with credentials provider support, such as AWS SDK-integrated clients, is strongly recommended. These clients are designed to manage token generation and refresh processes seamlessly, eliminating the need for custom scheduling logic. This solution streamlines the implementation and significantly mitigates the risk of token expiration.

  4. Is there anything that we missing to consider when we are doing this auth token refresh?

  • Ensure that the token refresh logic is designed to be thread-safe, effectively preventing race conditions.
  • Continuously evaluate the performance impact associated with frequent pool re-creation, particularly under high-load scenarios.
  • Develop and implement comprehensive error-handling mechanisms to manage token refresh failures or pool re-creation issues gracefully and efficiently.
  1. Is there any other mechanism that we can use instead of the background scheduler?
  • In scenarios where migrating to a client with credentials provider support is not viable, it is advisable to utilize a connection pool library capable of dynamically reconfiguring authentication credentials, eliminating the need for frequent pool re-creation.
  • Consider leveraging AWS Lambda or other serverless technologies to facilitate token generation and distribution, thereby reducing the operational burden on your application.
EXPERT
answered a year ago
  • Vaddineni, Sai Priya
    a year ago

    Thank you for you response!! This is very much useful!

    I've few follow up questions:

    1. I'm not quite familiar with redis client with credential provider support, but do they automatically refresh token on a long-lived server?! I mean does it makes sure that the requests that comes through uses the latest token?
    2. Are you aware of any connection pool library capable of dynamically reconfiguring authentication credentials?
    3. So reg the lambda comment, lambda handles the token rotation and we should either call lambda for every request or schedule to retrieve the token which might be same as scheduling token refresh every 5/7 mins right?!
    4. If we have a custom AWSCredentialsProvider, that refreshes creds for example every 1 hour and valid for like 6 hours (like something mentioned here:https://medium.com/expedia-group-tech/service-slow-to-retrieve-aws-credentials-ebc02a38e95b), this shouldn't cause any intermittent failures of invalid auth token right?
0

Hey,

Hope you're keeping well.

Your approach of refreshing the IAM auth token and rebuilding the JedisPool is correct given the 15‑minute validity, but you can reduce churn by timing the refresh closer to expiry, for example around 12–13 minutes after generation. If possible, consider switching to a Redis client that supports AWS credential providers natively, as that removes the need to manage pool recreation logic. Also ensure your scheduler logic handles token generation failures gracefully to avoid dropping all connections. For production, test the switchover under load to confirm no spikes in latency during pool replacement.

Thanks and regards,
Taz

answered 4 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content