connector tasks.max Within [1, 16]

Cap connector parallelism. Runaway tasks.max is the #1 way to DoS your own Connect cluster.

Rationale

A developer sets `tasks.max: 200` thinking "more = faster" and starves every other connector on the cluster (Connect schedules tasks round-robin across workers). The upper bound also forces a conversation about why the source actually needs that much parallelism. Usually it does not. Floor of 1 catches the YAML typo `tasks.max: 0`.

Pattern

1 <= tasks.max <= 16

Examples

Parameters

Implementation

Drop this YAML into Conduktor Console as a ResourcePolicy, then link it from an ApplicationInstance, Application, or KafkaCluster.

# Conduktor self-service ResourcePolicy
# Connector exposes spec.config (singular); every value is a string.
---
apiVersion: self-serve/v1
kind: ResourcePolicy
metadata:
  name: connector-tasks-max-bound
spec:
  targetKind: Connector
  description: tasks.max must be in [1, 16]
  rules:
    - condition: '"tasks.max" in spec.config && int(string(spec.config["tasks.max"])) >= 1 && int(string(spec.config["tasks.max"])) <= 16'
      errorMessage: "tasks.max must be in [1, 16] — higher values starve other tenants on the Connect cluster"

Related policies

• Only Allow Vetted connector.class Plugins
• errors.tolerance=all Requires a DLQ
• No Inline Credentials in Connector Config
• JDBC Connector Host Allowlist
• Connector Topics Must Match Owning Tenant