Skip to content
Ask AI about this
Help improve this page

Redshift Serverless namespaces should not use the default database name

Default database names are predictable. Attackers and automated scanning tools try well-known defaults like "dev" first when probing endpoints. A non-default name won't stop a determined attacker, but it removes a predictable target and slows automated reconnaissance.

Beyond security, leaving "dev" as the database name in production creates operational confusion. Engineers reading connection strings can't distinguish environments at a glance, which raises the risk of running destructive queries against the wrong namespace.

Retrofit consideration

Renaming the database on an existing namespace requires building a new namespace with the desired db_name and migrating data into it. The db_name argument is ForceNew, so Terraform will destroy and recreate the resource, dropping all databases and schemas in the process.

Implementation

Choose the approach that matches how you manage Terraform.

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

resource "aws_redshiftserverless_namespace" "this" {
  admin_user_password = "PofixTest123!"
  admin_username      = "rsadmin"
  db_name             = "mydb"
  log_exports         = ["connectionlog", "userlog"]
  namespace_name      = "pofix-abc123"
}

What this control checks

The aws_redshiftserverless_namespace resource has a db_name argument that defaults to "dev" when omitted. Set it to any non-"dev" string, such as "analytics" or "warehouse", to pass. The control evaluates the resolved value at plan time, so both an explicit db_name = "dev" and a missing db_name argument fail. Any non-empty string other than "dev" passes.

Common pitfalls

  • Omitting db_name triggers the default

    Omitting db_name silently produces a "dev" database. Terraform shows no diff because the provider treats the default as the desired state, so the resource looks clean in terraform plan while still failing the control. Explicitly set db_name on every aws_redshiftserverless_namespace resource, even if you think the provider will inherit a sensible value.

  • Changing db_name forces resource replacement

    The db_name argument is ForceNew in the AWS provider. Updating it on an existing namespace destroys and recreates the resource, deleting all databases and schemas inside it. Migrate data to a separate namespace first, confirm the migration is clean, then apply the rename.

  • Connection strings hardcoded to dev

    After renaming, any application, JDBC URL, or Secrets Manager entry still referencing "dev" will fail with a database-not-found error. Audit every consumer of the namespace before applying the change, not after.

Audit evidence

Terraform plan or state output for each aws_redshiftserverless_namespace showing db_name set to a value other than "dev". Supplement with aws redshift-serverless list-namespaces output confirming no namespace reports "dbName": "dev". Both sources together give an auditor configuration-as-code evidence alongside live infrastructure verification.

Tool mappings

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

  • Compliance.tf Control: redshiftserverless_namespace_no_default_database_username

  • AWS Config Managed Rule: REDSHIFT_SERVERLESS_DEFAULT_DB_NAME_CHECK

  • Checkov Check: CKV_AWS_320

  • Powerpipe Control: aws_compliance.control.redshiftserverless_namespace_no_default_database_username

Last reviewed: 2026-03-09