🛡️ AWS MSK Cluster Kafka version is outside support🟢

• Contextual name: 🛡️ Cluster Kafka version is outside support🟢
• ID: /ce/ca/aws/msk/cluster-kafka-version-support
• Tags:
  • 🟢 Policy with categories
  • 🟢 Policy with type
  • 🟢 Production policy
• Policy Type: COMPLIANCE_POLICY
• Policy Categories: RELIABILITY

Stats

not available

Logic

• 🧠 prod.logic.yaml🟢
  • 📗 AWS MSK Cluster
  • 🔌 AWS MSK Cluster - object.extracts.yaml
  • 🧪 test-data.json

Description

Open File

Description

This policy checks an Amazon MSK Provisioned cluster's Current Broker: Kafka Version against the AWS MSK support calendar. It preserves AWS identifiers such as .kraft and .tiered. Current Version is a cluster revision token and is not assessed as a Kafka release. A supported version does not have to be the latest version.

Rationale

Using supported broker software reduces security and maintenance risk. AWS can automatically upgrade clusters after a version's end of support without advance notification. Findings let owners verify discovery and schedule a tested upgrade instead of relying on that automatic upgrade. Kafka's upstream lifecycle does not establish Amazon MSK's support status.

Impact

Upgrades can change client compatibility, configuration requirements, and metadata management. Plan and test the upgrade rather than relying on an automatic service upgrade. A retained CMDB version is not proof that AWS still runs that version after its automatic upgrade window.

Audit

This policy marks an AWS MSK Cluster as INCOMPLIANT if its State is ACTIVE, UPDATING, HEALING, MAINTENANCE, or REBOOTING_BROKER and its Current Broker: Kafka Version matches one of the versions below, whose published AWS End of support date has passed.

... see more

Remediation

Open File

Remediation

1. Verify the live cluster's deployment type, current broker Kafka version, and state in the Amazon MSK console or with the describe-cluster-v2 command in the Audit section. Refresh Cloudaware discovery if AWS already completed an automatic upgrade. Serverless versions are managed by AWS; do not apply the Provisioned upgrade procedure to a Serverless cluster.

2. Check the current AWS support calendar and identify a supported target compatible with the cluster's broker type, metadata mode, and tiered-storage configuration. Kafka 4.2 currently requires Express brokers. Do not remove .kraft or .tiered from identifiers when selecting an upgrade path.

3. Review the available in-place upgrade targets:

   aws kafka get-compatible-kafka-versions \
       --region {{region-name}} \
       --cluster-arn {{cluster-arn}}

4. Test producer and consumer clients, Kafka Streams applications, connectors, authentication, custom broker configurations, and operational tooling against the target. Confirm replication health and sufficient capacity for rolling broker restarts. Review the metadata migration requirements when moving from ZooKeeper to KRaft; AWS supports in-place migration for eligible upgrade paths. Preserve the required custom configuration and select a compatible configuration revision if it must change.

... see more

policy.yaml

Open File

Linked Framework Sections

Section	Sub Sections	Internal Rules	Policies	Flags	Compliance
💼 Cloudaware Framework → 💼 Infrastructure Modernization			39		no data