Repository navigation
Conversation
…lkey (ElastiCache) When no password is configured and the host is an Amazon RDS or ElastiCache endpoint, log in with short-lived IAM tokens signed from the ambient AWS credentials. Password authentication is unchanged.
… a dedicated role When set, the instance/machine role first assumes AWS_INTEGRATION_ROLE_ARN and target roles are assumed from it, so the role integrations trust can stay separate from the role the application runs as. Unset, behaviour is unchanged; AWS_INTEGRATION_ACCESS_KEY_ID/SECRET still take precedence.
Password-based setups resolve exactly as before, IAM only switches on for passwordless RDS/ElastiCache endpoints, tokens are signed per connection and fail loudly without region or credentials, and AWS_INTEGRATION_ROLE_ARN is strictly opt-in with integration access keys still taking precedence.
The signer only holds weak references into the session's event hooks. The session was a local in _signer(), so once it was garbage-collected every new Redis connection failed with ReferenceError. Long-running RQ workers hit this on staging; the regression test forces a collection between connections.
- Redis IAM is now opt-in via REDIS_IAM_CACHE_NAME (the replication group ID). The group can't be derived reliably from the endpoint (older endpoint formats, custom DNS names), and explicit opt-in means a passwordless ElastiCache user is never switched to IAM by accident. - IAM tokens are only sent over TLS: Redis IAM refuses to start without REDIS_SSL, and Postgres uses IAM only when DATABASE_SSL is on. - Dynamic secrets that use their own access keys no longer build an STS client, so they don't depend on the AWS_INTEGRATION_ROLE_ARN hop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Lets the backend authenticate to Amazon RDS and ElastiCache with short-lived IAM tokens instead of static passwords, using the ambient AWS credentials (e.g. an ECS task role).
Opt-in, no new configuration. IAM auth is used only when no password is set and the host is an AWS endpoint:
DATABASE_PASSWORDunset +DATABASE_HOSTending in.rds.amazonaws.comREDIS_USERset,REDIS_PASSWORDunset +REDIS_HOSTending in.cache.amazonaws.com(TLS replication-group endpoints)Region comes from the standard
AWS_DEFAULT_REGION. Password authentication is unchanged: the settings diff is additions only, and with a password set the resultingDATABASES,CACHESandRQ_QUEUESare identical to before.How: a thin subclass of Django's PostgreSQL backend sets the password to an RDS auth token at connect time; a redis-py
CredentialProviderdoes the same for ElastiCache and is passed to the cache and RQ queues. Tokens are signed locally and only checked when a connection opens.Testing: unit tests for both token paths and provider pickling; settings verified under both configurations.