MSK Connect connectors should be encrypted in transit

MSK Connect connectors shuttle data between Apache Kafka clusters and external systems like S3, databases, and search indexes. Without TLS, that data moves in cleartext across the network, exposing it to interception. This is especially dangerous in multi-tenant VPCs or when connectors communicate across availability zones, where traffic traverses shared physical infrastructure.

Connectors are non-compliant unless encryption_type is explicitly set to TLS in the kafka_cluster_encryption_in_transit block. There is no implicit default to encrypted transport.

Retrofit consideration

Changing encryption_type from PLAINTEXT to TLS forces replacement of the connector resource, causing downtime for the connector's data pipeline.

Implementation

Choose the approach that matches how you manage Terraform.

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

resource "aws_mskconnect_connector" "this" {
  capacity {
    provisioned_capacity {
      mcu_count    = 1
      worker_count = 1
    }
  }
  connector_configuration = { "topic" = "pofix-example-topic" }

  kafka_cluster {
    apache_kafka_cluster {
      bootstrap_servers = "b-1.example.kafka.us-east-1.amazonaws.com:9092"

      vpc {
        security_groups = ["sg-12345678"]
        subnets         = ["subnet-12345678"]
      }
    }
  }

  kafka_cluster_client_authentication {
    authentication_type = "NONE"
  }

  kafkaconnect_version = "2.7.1"
  name                 = "pofix-abc123"

  plugin {
    custom_plugin {
      arn      = "arn:aws:kafkaconnect:us-east-1:123456789012:custom-plugin/example/1"
      revision = 1
    }
  }

  service_execution_role_arn = "arn:aws:iam::123456789012:role/example-role"

  kafka_cluster_encryption_in_transit {
    encryption_type = "TLS"
  }
}

What this control checks

The aws_mskconnect_connector resource includes a kafka_cluster_encryption_in_transit block with an encryption_type argument. A configuration passes when encryption_type is "TLS". It fails when the value is "PLAINTEXT" or the block is omitted entirely. The underlying MSK cluster must also support TLS: encryption_in_transit on the aws_msk_cluster must have client_broker set to TLS or TLS_PLAINTEXT, otherwise the connector will fail to establish a TLS connection at apply time even if the connector-side config is correct.

Common pitfalls

Explicit TLS setting is required

Omitting kafka_cluster_encryption_in_transit entirely, or leaving encryption_type unset, fails this control. There is no default to TLS: set encryption_type = "TLS" explicitly in the block.

Changing encryption forces connector replacement

encryption_type is marked ForceNew in the AWS provider. Switching from PLAINTEXT to TLS destroys and recreates the aws_mskconnect_connector, interrupting data flow. Plan a maintenance window before applying this change.

MSK cluster must support TLS on the broker side

Setting the connector to TLS against a cluster with client_broker = "PLAINTEXT" fails at apply time. The aws_msk_cluster resource must have client_broker set to TLS or TLS_PLAINTEXT before the connector can negotiate TLS successfully.

Custom plugins need compatible security configuration

Even with encryption_type = "TLS" set on the connector, worker configuration properties can undermine it. If security.protocol=PLAINTEXT appears in aws_mskconnect_worker_configuration or the connector's custom config properties, the connection falls back to plaintext. Audit both the worker config and connector properties before applying.

Audit evidence

Config rule evaluations on AWS::KafkaConnect::Connector resources confirm whether encryptionType within kafkaClusterEncryptionInTransit is TLS. The MSK Connect console displays the encryption configuration per connector under its details tab. The aws kafkaconnect describe-connector CLI command returns the full kafkaClusterEncryptionInTransit object, providing a per-connector artifact suitable for automated evidence collection or point-in-time screenshots.

Framework-specific interpretation

SOC 2: CC6.7 asks for controls that restrict unauthorized data transmission. TLS on MSK Connect connectors is direct evidence that data moving between Kafka and external systems travels over encrypted channels. CC6.1 is also relevant where broker connectivity crosses access control boundaries.

ISO/IEC 27001:2022: A.8.24 (Use of cryptography) and A.8.26 (Application security requirements) both apply here. A.8.24 expects cryptographic controls on data in transit; encryption_type = "TLS" on MSK Connect connectors covers that for integration pipeline traffic. A.8.26 reinforces the expectation at the application layer.

NIS2 Directive (EU 2022/2555): Article 21 requires essential and important entities to implement encryption as part of their security measures. For operational data streams passing through MSK Connect, TLS in transit is the expected implementation of that requirement.

NIST Cybersecurity Framework v2.0: PR.DS (Data Security) under the Protect function covers confidentiality and integrity of data in transit. Enforcing TLS on MSK Connect connectors directly addresses that outcome, preventing interception of data moving between brokers and external systems.

Tool mappings

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

Compliance.tf Control: mskconnect_connector_encryption_in_transit_with_tls_enabled
Powerpipe Control: aws_compliance.control.mskconnect_connector_encryption_in_transit_with_tls_enabled
Prowler Check: kafka_connector_in_transit_encryption_enabled
AWS Security Hub Control: MSK.3

Last reviewed: 2026-03-09