MSK clusters should disable unauthenticated access

An MSK cluster with unauthenticated access enabled allows any client with network connectivity to produce and consume messages without presenting credentials. This means a compromised EC2 instance or container in the same VPC can read sensitive event streams or inject malicious messages into topics, no credentials required.

Disabling unauthenticated access forces all clients to authenticate via SASL/SCRAM, SASL/IAM, or mutual TLS. This gives you an enforcement point for topic-level ACLs and lets CloudTrail log the identity behind each connection, which matters for both incident response and data governance.

Retrofit consideration

Disabling unauthenticated access on a running cluster requires all existing clients to be reconfigured with credentials before the change takes effect. MSK performs a rolling broker restart, and any client that hasn't been updated will lose connectivity mid-rollout.

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 "msk_kafka_cluster" {
  source  = "registry.compliance.tf/terraform-aws-modules/msk-kafka-cluster/aws"
  version = ">=3.0.0"

  broker_node_client_subnets  = ["subnet-12345678", "subnet-12345678", "subnet-12345678"]
  broker_node_instance_type   = "kafka.t3.small"
  broker_node_security_groups = ["sg-12345678"]
  client_authentication = {
    sasl = {
      iam = true
    }
  }
  kafka_version          = "3.6.0"
  name                   = "abc123"
  number_of_broker_nodes = 3
}

This control is enforced automatically with Compliance.tf modules. Start free trial

If you use terraform-aws-modules/msk-kafka-cluster/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 "msk_kafka_cluster" {
  source  = "terraform-aws-modules/msk-kafka-cluster/aws"
  version = ">=3.0.0"

  broker_node_client_subnets  = ["subnet-12345678", "subnet-12345678", "subnet-12345678"]
  broker_node_instance_type   = "kafka.t3.small"
  broker_node_security_groups = ["sg-12345678"]
  kafka_version               = "3.6.0"
  name                        = "abc123"
  number_of_broker_nodes      = 3

  client_authentication = {
    unauthenticated = false
  }
}

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

resource "aws_msk_cluster" "this" {
  broker_node_group_info {
    client_subnets  = [element(["subnet-abc123", "subnet-def456"], 0), element(["subnet-abc123", "subnet-def456"], 1)]
    instance_type   = "kafka.t3.small"
    security_groups = ["sg-abc12345"]
  }
  cluster_name           = "pofix-abc123"
  kafka_version          = "3.5.1"
  number_of_broker_nodes = 2

  client_authentication {
    sasl {
      iam = true
    }
    unauthenticated = false
  }
}

What this control checks

The client_authentication block in aws_msk_cluster controls how clients connect. Set unauthenticated = false (or omit it when at least one authenticated method is configured). Also enable one or more authentication mechanisms: sasl { iam = true }, sasl { scram = true }, or tls { certificate_authority_arns = [...] }. Setting unauthenticated = true fails the control regardless of whether other authentication methods are also enabled. If client_authentication is omitted entirely, don't assume compliance; verify the effective cluster settings to confirm unauthenticated access is disabled.

Common pitfalls

Omitting client_authentication can cause unintended auth posture

Omitting client_authentication from aws_msk_cluster doesn't mean the cluster defaults to a secure configuration. Always explicitly declare your authentication settings and verify in the console that unauthenticated access is actually disabled.

Enabling unauthenticated alongside SASL or TLS still fails

MSK allows unauthenticated = true even when sasl or tls is also configured. This mixed mode lets unauthenticated clients bypass your ACLs entirely. The control checks the unauthenticated flag independently, so having SASL/IAM enabled doesn't compensate.

Listener port changes on authentication mode switch

Switching from unauthenticated to SASL/IAM changes the broker endpoint ports: 9098 for IAM, not 9092 for plaintext. Any client not updated to the new port and corresponding authentication library will fail to connect.

Serverless MSK uses a different resource

The aws_msk_serverless_cluster resource always requires IAM authentication and does not expose an unauthenticated toggle. This control applies only to provisioned aws_msk_cluster resources.

Audit evidence

AWS Config rule evaluation results showing COMPLIANT status for each MSK cluster confirm unauthenticated access is disabled. Supporting evidence includes the DescribeCluster or DescribeClusterV2 API response where ClientAuthentication.Unauthenticated.Enabled is false and at least one authentication method (SASL/IAM, SASL/SCRAM, or TLS) is enabled. Console screenshots of the cluster's "Security settings" tab are acceptable. CloudTrail events for UpdateSecurity calls show when unauthenticated access was disabled and by whom.

Tool mappings

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

Compliance.tf Control: msk_cluster_unauthenticated_access_disabled
AWS Config Managed Rule: MSK_UNRESTRICTED_ACCESS_CHECK
Powerpipe Control: aws_compliance.control.msk_cluster_unauthenticated_access_disabled
Prowler Check: kafka_cluster_unrestricted_access_disabled
AWS Security Hub Control: MSK.6

Last reviewed: 2026-03-09