Amazon MSK Security Review Checklist for Regulated Streaming Workloads

A regulated Kafka workload is rarely rejected because one checkbox is missing. The harder failure is a control that exists in one layer but is not owned, observable, or testable in the next layer. A cluster may use TLS while a connector still holds a long-lived password. A private subnet may protect the broker endpoint while a broad security group allows every application in the VPC to connect. CloudTrail may prove who changed the cluster, while no one can show which identity could read a sensitive topic.

An Amazon MSK security review should follow the data path and the evidence path together. Start with the records in scope, map them to accounts, networks, identities, encryption keys, Kafka permissions, and retention rules, then verify that each control leaves evidence an auditor can inspect.

1Start with data classification and control ownership

Write down what each topic carries before reviewing how the cluster is configured. A topic holding payment events, customer identifiers, or internal telemetry may have different retention, access, and incident requirements. Classification does not need to expose the data in the review package. It needs to identify the control level that applies to the topic and the person accountable for it.

A useful inventory has one row per data domain or topic family:

Keep the inventory separate from live message payloads, and name the owner for cluster configuration, IAM roles, ACLs, connector secrets, and rotation tests. An unnamed control is an exception even when the setting looks correct.

2Account and network boundary

Amazon MSK runs inside an Amazon VPC. Review the AWS account and network placement as an explicit security boundary, not as a deployment detail.

Confirm that:

• Production and non-production clusters use the intended AWS accounts and Regions.
• The cluster subnets, route tables, security groups, and VPC connectivity match the approved architecture.
• Broker ingress is limited to the application networks and ports that require it.
• Administrative access follows the organization’s private access path; a public route is not assumed merely because a client can resolve a name.
• Cross-account producers, consumers, connectors, and operators have a documented trust path and an owner.
• VPC endpoints, transit gateways, peering, or other network services are included in the review when they carry MSK traffic.

Security groups are a useful enforcement point, but they are not Kafka authorization. A rule that permits a client to reach a broker says nothing about whether that client may read a topic. Record the source security group or network range for each approved client class, then review whether the rule is narrower than the VPC itself.

A network test should prove both the expected path and an unwanted path. From an approved workload, verify broker reachability and TLS negotiation; from an unapproved subnet or security group, verify refusal. Capture the test date, source identity, destination, and result.

3Identity, authentication, and Kafka authorization

Amazon MSK supports several client authentication patterns, including IAM access control, SASL/SCRAM, and mutual TLS. The review should capture the identity source, the authentication mechanism, and the authorization source for every client class. Do not use “TLS enabled” as shorthand for all three.

For each producer, consumer, connector, and operator, answer these questions:

1. Which AWS role, Secrets Manager secret, or certificate identifies the client?
2. Which Kafka security protocol and authentication mechanism does the client use?
3. Where is the permission to read, write, create, alter, or describe granted?
4. How is the identity rotated or revoked?
5. What evidence shows that the client recovers after a rotation?

IAM-authenticated clients use IAM policies for Kafka actions. Kafka ACL APIs do not authorize IAM identities, so an ACL change is not a fix for an IAM policy denial. For SCRAM and mutual TLS clients, Kafka ACLs remain part of the authorization model. This split should appear in the control matrix and in the incident runbook.

Use a distinct principal for each workload or connector with a materially different access need. Sharing one identity across a producer fleet may simplify provisioning, but it weakens attribution and enlarges the blast radius of a leaked credential. A useful permission review names the exact topic and consumer-group resources, the allowed operations, and whether cluster-level operations are necessary.

Test denial as deliberately as success. Remove one permission in a non-production environment and confirm that the client receives an authorization failure while unrelated clients continue to work. This demonstrates that the rule is attached to the expected principal and that the review is not relying on an overly broad role or ACL.

4Encryption in transit and at rest

Encryption is a set of control decisions with different owners. Review broker-to-client transport, broker-to-broker traffic, storage encryption, key management, and any external sink separately.

For encryption in transit, verify that clients use the approved TLS or SASL-over-TLS configuration and validate the broker certificate. If mutual TLS is used, record the Private CA owner, certificate subject mapping, trust-store distribution, renewal window, and compromise response. A certificate proves possession of a trusted key; Kafka authorization still decides which topics that principal can access.

For encryption at rest, review the MSK cluster setting and its AWS KMS key. If the workload requires a customer managed key, retain the key ARN, key policy, rotation setting, and the role or service principals allowed to use it. The KMS policy is part of the data path: an otherwise healthy cluster can lose access to encrypted data if a key is disabled or its policy is narrowed without a test.

Review encryption on every hop after MSK. A connector writing to object storage, a replication service crossing Regions, or an analytics consumer may introduce a second encryption and key policy boundary. The MSK cluster’s at-rest setting does not prove that the downstream destination has the same classification or retention controls.

5Secrets and credential lifecycle

Long-lived credentials are often the gap between a well-configured cluster and an auditable workload. Use the client’s supported identity provider and keep secret material out of source code, images, command history, and shared configuration files.

For SCRAM, review the associated Secrets Manager secret, its customer managed KMS key when required by MSK, the read permissions, and the rotation owner. A password rotation is not complete until the client has reconnected with the new value. For IAM, verify that the runtime obtains temporary credentials through its intended role rather than through static keys. For mutual TLS, review private-key storage, certificate renewal, trust-chain updates, and the restart or reload behavior of each client.

The rotation test should include a rollback decision:

• Record the current principal, secret or certificate version, and active clients.
• Stage the new material and confirm that the client can load it.
• Perform a real produce or consume test against an approved topic.
• Observe reconnects, errors, and lag during the change.
• Retire the old material only after the fleet is accounted for.
• Keep the previous version or certificate available for the documented rollback window.

6Audit logs and evidence

Separate control-plane audit from data-plane observability. AWS CloudTrail can record Amazon MSK API activity, such as cluster changes and configuration operations. It does not provide a record-level audit trail for every Kafka message or prove that a consumer read one particular record. Kafka broker logs and metrics can add operational evidence, but they need their own destination, retention, access policy, and time synchronization review.

Define the minimum evidence set before the review:

• Cluster ARN, account, Region, Kafka version, authentication mode, and encryption settings.
• VPC, subnet, route, and security-group configuration for approved client paths.
• IAM policies, Kafka ACL exports, secret metadata, certificate and CA ownership, and KMS key policy references.
• CloudTrail events for changes to the cluster and related AWS resources.
• Broker logs, client authentication failures, and operational metrics retained for the approved period.
• A dated result for network denial, authorization denial, credential rotation, and recovery tests.
• Exceptions with a risk owner, compensating control, expiry date, and next review date.

Evidence should be reproducible. An exported configuration, API response, policy version, or test log is easier to compare than a screenshot. Store the capture time and source account with every artifact, and give investigators read access without allowing them to rewrite or delete the logs.

7Retention, recovery, and incident response

Kafka retention is a workload setting, not automatically a compliance archive. Record the topic retention and cleanup policy, then compare them with business retention and legal-hold requirements. If the organization needs an independent copy, document the export, replication, or sink path and apply the same classification and encryption review to that destination.

A recovery test should answer a concrete question: after a broker, client identity, or Region-level disruption, how does the approved workload resume and how is data completeness demonstrated? Capture the expected recovery point and recovery time as workload requirements; do not infer them from the existence of replicas. Test consumer offsets, duplicate handling, ordering assumptions, and the permissions needed to restart connectors or applications.

Incident response needs a decision tree that starts with scope:

1. Contain: identify the principal, topic, account, and network path involved; restrict the affected role, ACL, secret, certificate, or security group.
2. Preserve: retain CloudTrail events, broker logs, client errors, and configuration versions before changing more than necessary.
3. Assess: determine whether the event is an authentication failure, authorization change, credential compromise, network expansion, or data-retention issue.
4. Recover: restore the minimum access required, rotate affected credentials, and verify a real produce or consume path.
5. Close: document data impact, evidence gaps, compensating controls, and the next review date.

8Build the review package

A compact control matrix might include:

Keep compliance language scoped. Amazon MSK features can support a control design, but the service setting alone does not establish compliance with a regulation. Your organization still owns data classification, access review, incident response, retention decisions, and evidence integrity.

9Where AutoMQ changes the deployment boundary

If the review is driven by data residency, network ownership, or control-plane separation, compare the deployment boundary as well as the Kafka API. AutoMQ BYOC documentation describes an environment and data plane installed in the customer’s cloud account and VPC, with Kafka ACLs and security controls managed for that deployment. That can change who owns the network, data-plane access path, and cloud audit evidence.

The same checklist still applies. Verify the exact deployment, identity mechanism, KMS and storage settings, log destinations, and recovery procedures for the version and cloud you are reviewing. A customer-controlled VPC changes a boundary; it does not by itself satisfy a regulatory requirement.

If portability is part of the decision, write down the security contract before migrating: client protocol, principal mapping, ACL behavior, encryption keys, credential rotation, audit records, and retention path. A Kafka-compatible API helps clients move; it does not automatically move an organization’s identity and evidence lifecycle.

Review AutoMQ BYOC deployment when the deployment boundary is part of your security decision.

10FAQ

10.1Does enabling TLS make an Amazon MSK workload compliant?

No. TLS protects data in transit, but compliance also depends on identity, authorization, key management, network controls, audit evidence, retention, and incident response. Review each control and its owner.

10.2Are Kafka ACLs enough for an MSK security review?

No. ACLs govern Kafka operations for the identities to which they apply. You still need IAM or secret controls, encryption, network restrictions, audit logging, retention rules, and tested recovery. IAM-authenticated clients use IAM policies for Kafka authorization.

10.3Does CloudTrail show who read a Kafka message?

CloudTrail records AWS API activity, including MSK control-plane changes. It is not a record-level audit log for every Kafka produce or consume operation. Use the approved Kafka and application observability path when record-level evidence is required.

10.4What should a security reviewer ask about an MSK connector?

Ask which identity the connector uses, where its secret or certificate is stored, which topics and consumer groups it can access, how it rotates credentials, and how it recovers after a denied request or restart.

10.5Do replicas replace an independent compliance backup?

Not automatically. Replicas support Kafka availability within the service’s operating model. If policy requires an independent copy, document the approved replication or export destination, its encryption, retention, access, and recovery test.

10.6How often should the checklist run?

Run it before production launch, after a material change to identity, network, encryption, retention, or client topology, and on the review interval required by your organization. Set an owner and expiry date for every exception.

11References

• Amazon MSK security overview
• Encryption at rest for Amazon MSK
• Authentication and authorization for Apache Kafka APIs
• IAM access control for Amazon MSK
• Mutual TLS authentication for Amazon MSK
• SASL/SCRAM authentication
• Apache Kafka ACLs on Amazon MSK
• Monitoring Amazon MSK with CloudWatch
• Logging Amazon MSK broker logs
• Logging Amazon MSK API calls with AWS CloudTrail
• Amazon MSK BYOC deployment documentation
• AutoMQ security documentation

To test a Kafka-compatible deployment boundary with your own security review, start with AutoMQ.