Skip to main content
emnode
Sign up
Compliance Medium severity

AWS Security Hub · ElastiCache

ElastiCache.6: Redis replication groups should have AUTH

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub ElastiCache.6 check?

ElastiCache.6 fails when a Redis OSS replication group on an engine version below 6.0 has no `AuthToken` set. The control targets only pre-6.0 clusters, because version 6.0 replaced AUTH with the richer RBAC/ACL model.

Why does ElastiCache.6 matter?

Redis historically shipped with no authentication, on the assumption it sat behind a firewall on a trusted network. That assumption fails badly in the cloud: scanners regularly find tens of thousands of unauthenticated Redis instances, many holding live session data. On a legacy cluster, an AUTH token is the only thing standing between a reachable endpoint and full read/write access.

How do I fix ElastiCache.6?

  1. List replication groups below engine 6.0 and check whether an `AuthToken` is set.
  2. Ensure in-transit encryption is on (AUTH requires it), then add or rotate an `AuthToken` using ElastiCache's no-downtime rotation strategy.
  3. Update clients to present the token on connect.
  4. Where practical, upgrade the engine to 6.0+ and adopt RBAC instead of bolting a password onto a legacy cluster.

Remediation script · bash

# Attach a JWT authorizer to an open API route, then redeploy the stage to enforce it.
aws apigatewayv2 update-route --api-id a1b2c3d4e5 \
  --route-id r7h8j9 --authorization-type JWT --authorizer-id auth9z8y
aws apigatewayv2 create-deployment --api-id a1b2c3d4e5 --stage-name '$default'

# Disable the unauthenticated listener on an MSK cluster while keeping IAM auth.
ARN=arn:aws:kafka:us-east-1:111122223333:cluster/orders-stream-prod/abc123
VERSION=$(aws kafka describe-cluster-v2 --cluster-arn $ARN \
  --query 'ClusterInfo.CurrentVersion' --output text)
aws kafka update-security --cluster-arn $ARN --current-version $VERSION \
  --client-authentication '{"Sasl":{"Iam":{"Enabled":true}},"Unauthenticated":{"Enabled":false}}'

# Once clients send the new credential, remove the AppSync API key to clear the finding.
aws appsync delete-api-key --api-id abcd1234efgh5678ijkl --id da2-examplekeyid12345

Full walkthrough (console steps, edge cases and verification) in the lesson Require authentication on data and API services.

Is ElastiCache.6 a false positive?

The control only evaluates replication groups on engine versions below 6.0, so a cluster that has been upgraded to 6.0+ and secured with RBAC/ACL users will pass on the engine-version check alone: RBAC is the recommended successor to AUTH and is not penalised. The case that looks like a false positive is a pre-6.0 cluster you have already scheduled to retire or upgrade: AUTH requires in-transit encryption, and on a legacy cluster turning both on can force a disruptive change you would rather fold into the upgrade. If so, treat it as a time-boxed exception: suppress the finding with a documented remediation date tied to the engine upgrade, rather than marking it permanently as not applicable, since the cluster is genuinely unauthenticated until then.

Full lesson Require authentication on data and API services Step-by-step remediation with CLI, code and persona-specific context.
AWS documentation for ElastiCache controls ↗ Check your own account for ElastiCache.6 →
Part of the learning path Lock down access

More ElastiCache controls