[Security Discussion]: elasticache_replication_group AuthTokenUpdateStrategy set to ROTATE allows passwordless login

[Phylu]

Description

Assume the following scenario:

• You are creating a redis cluster using elasticache_replication_group that does not have the auth_token variable set.
• You then update the elasticache_replication_group group by setting the auth_token variable.

After reading the documentation "(Optional) Password used to access a password protected server." [1], I would expect that the redis cluster can now only be accessed using the password.

However, passwordless access is still possible. This is due to the AuthTokenUpdateStrategy being set to ROTATE [2], which is what the ElastiCache documentation suggest: "After the modification is complete, the cluster supports the AUTH token specified in the auth-token parameter in addition to supporting connecting without authentication." [3].

I see this as an important security issue as the expected password protection is not in effect. I see the following possibilities

1. On the AWS side in should be possible to use the AuthTokenUpdateStrategy=SET when enabling an auth token for the first time. Then the provider can (and should) switch the AuthTokenUpdateStrategy accordingly.
2. If 1. is not possible on short notice (what I expect), it should be at least properly documented that when setting the auth_token for the first time, passwordless usage of the redis cluster is still possible. It must also be documented that when the auth_token is changed in terraform, a new token is set, but the old token is still active. (!)
3. In conjunction with 2., it should be possible to configure the AuthTokenUpdateStrategy using a terraform variable [4] in order to allow a real change of the auth token and not only adding a new auth token (while keeping the old one active).

What way forward do you suggest? I am happy to take care of the documentation change and might also give the additional variable a try if this makes sense.

References

[1] https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/elasticache_replication_group
[2] https://github.com/hashicorp/terraform-provider-aws/blob/cd2c2fbaf85651452e44eb0ff2a017ac0824d315/internal/service/elasticache/replication_group.go#L828C51-L828C51
[3] https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/auth.html#auth-modifyng-token
[4] #11524

Would you like to implement a fix?

Yes

[github-actions]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please see our prioritization guide for information on how we prioritize.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[jar-b]

Hey @Phylu - thank you for the detailed discussion! I wanted to share some context on the approach we're taking.

We've had a long standing issue (#11524) to address your third point of allowing practitioners to specify the auth_token_update_strategy explicitly. #34460 will enable this, with the caveat that the ROTATE strategy will, for now, be the default value if this argument is omitted. This was done to preserve backward compatibility in existing configurations which have auth_token set. If we went all the way to explicitly requiring the update strategy be provided when auth_token is set, a previously functioning configuration would fail.

To address the concerns raised here around the initial addition of an auth_token (where using the ROTATE strategy can allow both authenticated and unauthenticated access to the replication group), we've added an example to the documentation and a note stating that the SET strategy can be used in this case. Acceptance tests have also been updated to verify this pattern is valid. We're also planning to remove the default auth_token_update_strategy in the next major provider version (v6.0.0), after which an explicit value must be set by practitioners when enabling authentication. This should limit any unexpected behavior and return the responsibility of credential rotation patterns completely over to end users.

Please let us know if there is anything else you feel like should be included as part of this change!

[Phylu]

Hey @jar-b Awesome! This looks like a very good solution that is adressing the issue by updating the documentation and enabling a SET strategy immediately ith the planned option to remove the default ROTATE strategy in the next major version.

Thanks a lot for resolving this!

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.