AWS ElastiCache Redis Authentication Disabled

Critical Risk Infrastructure Security
awselasticacheredisauthenticationauth-tokenaccess-controlcache-securityterraformcloudformation

What it is

A critical authentication vulnerability where Amazon ElastiCache Redis clusters are configured without authentication tokens (AUTH), allowing unauthorized access to cached data. This enables attackers who gain network access to execute Redis commands, read sensitive cached information, modify application state, and potentially disrupt service operations. Without authentication, Redis clusters are vulnerable to unauthorized data access, cache poisoning, and command injection attacks.

# VULNERABLE: ElastiCache cluster without authentication
resource "aws_elasticache_replication_group" "redis_cache" {
  replication_group_id         = "app-cache"
  description                  = "Redis cluster for application caching"
  node_type                    = "cache.r6g.large"
  port                         = 6379
  parameter_group_name         = "default.redis7"
  num_cache_clusters           = 2
  
  # VULNERABLE: No authentication configured
  transit_encryption_enabled = false
  auth_token                = null
  # Anyone with network access can connect
  
  subnet_group_name = aws_elasticache_subnet_group.cache_subnet_group.name
  security_group_ids = [aws_security_group.cache_sg.id]
  
  automatic_failover_enabled = true
  multi_az_enabled          = true
  
  tags = {
    Environment = "production"
    Application = "web-app"
  }
}
# SECURE: ElastiCache cluster with authentication and encryption
resource "aws_elasticache_replication_group" "redis_cache" {
  replication_group_id         = "app-cache"
  description                  = "Redis cluster for application caching"
  node_type                    = "cache.r6g.large"
  port                         = 6379
  parameter_group_name         = "default.redis7"
  num_cache_clusters           = 2
  
  # SECURE: Enable transit encryption and AUTH token
  transit_encryption_enabled = true
  auth_token                = var.redis_auth_token  # Strong random password
  
  subnet_group_name = aws_elasticache_subnet_group.cache_subnet_group.name
  security_group_ids = [aws_security_group.cache_sg.id]
  
  automatic_failover_enabled = true
  multi_az_enabled          = true
  
  tags = {
    Environment = "production"
    Application = "web-app"
  }
}

# Generate secure random password for AUTH token
resource "random_password" "redis_auth_token" {
  length  = 64
  special = true
  upper   = true
  lower   = true
  numeric = true
}

# Store AUTH token securely in Secrets Manager
resource "aws_secretsmanager_secret" "redis_auth_token" {
  name        = "elasticache-redis-auth-token"
  description = "Authentication token for ElastiCache Redis"
}

resource "aws_secretsmanager_secret_version" "redis_auth_token" {
  secret_id = aws_secretsmanager_secret.redis_auth_token.id
  secret_string = random_password.redis_auth_token.result
}

💡 Why This Fix Works

The vulnerable example shows a Redis cluster without authentication, allowing any network-accessible client to connect and execute commands. The secure alternative implements AUTH tokens, transit encryption, secure token storage, and restrictive network access controls.

Why it happens

Development teams create Redis clusters without configuring authentication tokens, often due to complexity concerns or rapid prototyping needs. AUTH is disabled by default and requires transit encryption to be enabled, leading many deployments to operate without proper access controls. This commonly occurs when teams prioritize functionality over security.

Root causes

ElastiCache Cluster Without AUTH Token Configuration

Development teams create Redis clusters without configuring authentication tokens, often due to complexity concerns or rapid prototyping needs. AUTH is disabled by default and requires transit encryption to be enabled, leading many deployments to operate without proper access controls. This commonly occurs when teams prioritize functionality over security.

Missing Transit Encryption and Authentication Settings

Infrastructure code that creates ElastiCache clusters without enabling both transit_encryption_enabled and auth_token parameters. AUTH tokens require transit encryption to function, so both must be configured together. Teams often miss this dependency or avoid the configuration complexity, leaving clusters vulnerable to unauthorized access.

Fixes

1

Enable Transit Encryption and AUTH Token

Configure both transit_encryption_enabled = true and auth_token with a strong, randomly generated password. Store AUTH tokens securely in AWS Secrets Manager and rotate them regularly. Ensure all client applications are updated to use the AUTH token when connecting to Redis.

2

Implement Network-Level Security Controls

Combine authentication with VPC security groups that restrict access to authorized sources only. Use private subnets for Redis clusters and implement network ACLs for additional protection. Never expose Redis clusters to public networks, even with authentication enabled.

3

Monitor and Audit Cache Access

Enable Redis slow log and CloudWatch monitoring to track authentication failures and suspicious activity. Set up alerting for failed authentication attempts or unusual command patterns. Implement regular security assessments of cache access patterns and client configurations.

Detect This Vulnerability in Your Code

Sourcery automatically identifies aws elasticache redis authentication disabled and many other security issues in your codebase.

Scan Your Code for Free Explore More Vulnerabilities