Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

InvalidParameterCombination: Transit encryption preferred is not supported with redis access control. #239

Closed
syphernl opened this issue Jun 17, 2024 · 1 comment · Fixed by #238
Labels
bug 🐛 An issue with the system

Comments

@syphernl
Copy link
Contributor

syphernl commented Jun 17, 2024

Describe the Bug

After updating to https://github.com/cloudposse/terraform-aws-elasticache-redis/releases/tag/1.4.0 a terraform apply is failing with

InvalidParameterCombination: Transit encryption preferred is not supported with redis access control.

Expected Behavior

No error

Steps to Reproduce

  • Setup a Redis instance using 1.3.0, this works fine
  • Change the version to 1.4.0 and get the error above.

Screenshots

No response

Environment

hashicorp/aws v5.54.1

Additional Context

This is the resource it wants to create:

  + resource "aws_elasticache_replication_group" "default" {
      + apply_immediately              = true
      + arn                            = (known after apply)
      + at_rest_encryption_enabled     = false
      + auth_token                     = (sensitive value)
      + auth_token_update_strategy     = "ROTATE"
      + auto_minor_version_upgrade     = (known after apply)
      + automatic_failover_enabled     = false
      + cluster_enabled                = (known after apply)
      + configuration_endpoint_address = (known after apply)
      + data_tiering_enabled           = false
      + description                    = "example-staging-redis-sessions"
      + engine                         = "redis"
      + engine_version                 = "7.1"
      + engine_version_actual          = (known after apply)
      + global_replication_group_id    = (known after apply)
      + id                             = (known after apply)
      + ip_discovery                   = (known after apply)
      + maintenance_window             = "wed:03:00-wed:04:00"
      + member_clusters                = (known after apply)
      + multi_az_enabled               = false
      + network_type                   = (known after apply)
      + node_type                      = "cache.t4g.micro"
      + num_cache_clusters             = 1
      + num_node_groups                = (known after apply)
      + parameter_group_name           = "example-staging-redis-sessions-redis7"
      + port                           = 6379
      + primary_endpoint_address       = (known after apply)
      + reader_endpoint_address        = (known after apply)
      + replicas_per_node_group        = (known after apply)
      + replication_group_id           = "example-staging-redis-sessions"
      + security_group_ids             = [
          + "sg-01e0e15d341a8b50f",
        ]
      + security_group_names           = (known after apply)
      + snapshot_retention_limit       = 0
      + snapshot_window                = "06:30-07:30"
      + subnet_group_name              = "example-staging-redis-sessions"
      + tags                           = {
          + "Attributes" = "sessions"
          + "Name"       = "example-staging-redis-sessions"
          + "Namespace"  = "example"
          + "Stage"      = "staging"
        }
      + tags_all                       = {
          + "Attributes" = "sessions"
          + "Name"       = "example-staging-redis-sessions"
          + "Namespace"  = "example"
          + "Stage"      = "staging"
        }
      + transit_encryption_enabled     = true
      + transit_encryption_mode        = "preferred"
        # (1 unchanged attribute hidden)
    }

For 1.3.0 this is:

      + transit_encryption_enabled     = true
      + transit_encryption_mode        = (known after apply)

Due to the validation rules transit_encryption_mode cannot be set to null to get the old behavior back.

Related PR: #231

@syphernl syphernl added the bug 🐛 An issue with the system label Jun 17, 2024
@syphernl
Copy link
Contributor Author

Its still early, I see a PR has already been created to fix this: #238

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🐛 An issue with the system
Projects
None yet
1 participant