Skip to content
Ask AI about this
Help improve this page

Redshift clusters should not use the default database name

Default database names are well-known to attackers. When a Redshift cluster keeps the "dev" database name, automated scanning tools and credential-stuffing scripts can target it without any guesswork. Changing the database name adds a small but real layer of obscurity that forces an attacker to enumerate database names after gaining network access.

Beyond security, using "dev" in production creates confusion across environments. Engineers connecting to the wrong cluster may not realize they are querying production data if every environment shares the same database name.

Retrofit consideration

Changing the database name on an existing Redshift cluster requires creating a new cluster with the desired name and migrating data. The database_name argument in aws_redshift_cluster is a ForceNew attribute, meaning Terraform will destroy and recreate the cluster if you change it.

Implementation

Choose the approach that matches how you manage Terraform.

Use the compliance.tf module to enforce this control by default. See get started with compliance.tf.

module "redshift" {
  source  = "nistcsfv11.compliance.tf/terraform-aws-modules/redshift/aws"
  version = ">=7.0.0,<8.0.0"

  automated_snapshot_retention_period = 7
  cluster_identifier                  = "abc123"
  create_cloudwatch_log_group         = true
  database_name                       = "mydb"
  logging = {
    log_destination_type = "cloudwatch"
    log_exports          = ["connectionlog", "userlog", "useractivitylog"]
  }
  master_password_wo     = "change-me-in-production"
  master_username        = "admin"
  node_type              = "ra3.xlplus"
  number_of_nodes        = 2
  subnet_ids             = ["subnet-12345678", "subnet-12345678", "subnet-12345678"]
  vpc_id                 = "vpc-12345678"
  vpc_security_group_ids = ["sg-12345678"]
}

If you use terraform-aws-modules/redshift/aws, set the right module inputs for this control. You can later migrate to the compliance.tf module with minimal changes because it is compatible by design.

module "redshift" {
  source  = "terraform-aws-modules/redshift/aws"
  version = ">=7.0.0,<8.0.0"

  automated_snapshot_retention_period = 7
  cluster_identifier                  = "abc123"
  create_cloudwatch_log_group         = true
  database_name                       = "mydb"
  logging = {
    log_destination_type = "cloudwatch"
    log_exports          = ["connectionlog", "userlog", "useractivitylog"]
  }
  master_password_wo     = "change-me-in-production"
  master_username        = "admin"
  node_type              = "ra3.xlplus"
  number_of_nodes        = 2
  subnet_ids             = ["subnet-12345678", "subnet-12345678", "subnet-12345678"]
  vpc_id                 = "vpc-12345678"
  vpc_security_group_ids = ["sg-12345678"]
}

Use AWS provider resources directly. See docs for the resources involved: aws_redshift_cluster.

resource "aws_redshift_cluster" "this" {
  automated_snapshot_retention_period = 7
  cluster_identifier                  = "pofix-abc123"
  cluster_subnet_group_name           = "example-redshift-subnet-group"
  master_password                     = "ChangeMe123!"
  master_username                     = "admin"
  node_type                           = "ra3.large"
  skip_final_snapshot                 = true
}

What this control checks

In the aws_redshift_cluster resource, database_name defaults to "dev" when omitted. The control passes when it is set to any other non-empty value, such as "warehouse" or "analytics". It fails when the argument is absent or explicitly set to "dev". No other resources or arguments are evaluated.

Common pitfalls

  • Omitting database_name uses the default

    Many Terraform examples omit database_name entirely because it's optional. The provider silently uses "dev" as the default, so any cluster provisioned without this argument will fail immediately. Set it explicitly on every cluster resource.

  • Renaming requires cluster replacement

    database_name is a ForceNew attribute. Change it on an existing cluster and terraform apply will destroy and recreate it, taking your data with it. Snapshot first using aws redshift create-cluster-snapshot, and consider adding a prevent_destroy lifecycle block to catch accidental destruction before it happens.

  • Snapshot restores and database name behavior

    When restoring from a snapshot via snapshot_identifier, the resulting cluster can be given a new database_name at creation time. Skip that argument and the original name is reused. If the source cluster used "dev", the restore will too, and it will fail this control.

Audit evidence

Config rule evaluation results showing all clusters as compliant is the primary artifact. Console screenshots of the cluster configuration page showing the database name field can supplement this. Security Hub findings for this control should show PASSED across all clusters in all active regions.

For periodic assessments, output from aws redshift describe-clusters filtered on the DBName field gives direct evidence. Any cluster returning "dev" is a finding.

Framework-specific interpretation

NIST Cybersecurity Framework v1.1: PR.AC and PR.IP both apply. Predictable default identifiers like "dev" give automated scanners a free guess on database names, which is exactly what PR.AC's attack surface reduction is trying to prevent. Setting a custom name at deployment time is the kind of configuration hardening PR.IP expects.

Tool mappings

Use these identifiers to cross-reference this control across tools, reports, and evidence.

  • Compliance.tf Control: redshift_cluster_no_default_database_name

  • AWS Config Managed Rule: REDSHIFT_DEFAULT_DB_NAME_CHECK

  • Checkov Check: CKV_AWS_320

  • Powerpipe Control: aws_compliance.control.redshift_cluster_no_default_database_name

  • Prowler Check: redshift_cluster_non_default_database_name

  • AWS Security Hub Control: Redshift.9

Last reviewed: 2026-03-09