What the customer provides
| Field | Purpose |
|---|---|
| Bootstrap servers | A comma-separated list of host:port endpoints for the Kafka brokers. |
| Security protocol | PLAINTEXT, SSL, SASL_PLAINTEXT, or SASL_SSL. Confluent Cloud and MSK with IAM use SASL_SSL. |
| SASL mechanism + credentials (if SASL) | PLAIN, SCRAM-SHA-256, SCRAM-SHA-512, OAUTHBEARER, or AWS_MSK_IAM plus the corresponding username/password (or IAM role reference). |
| mTLS client certificate + key (if mTLS) | Alternative to SASL for client identity. |
| CA certificate (optional) | The trust anchor for the brokers’ TLS certificates when using a private CA. |
| Schema registry URL (optional) | If your application uses Avro / Protobuf schemas, the Confluent Schema Registry or compatible endpoint. |
| Topic prefix or allow-list (optional) | A namespace prefix for the appliance’s topics, or an explicit list of topic names the appliance is permitted to use. |
What changes in the deployment stack
When customer-provided Kafka is selected, the compiler:- Drops the default-shipped Kafka cluster from the deployment stack (no MSK cluster, no in-cluster Strimzi or Bitnami Kafka, no Zookeeper / KRaft controllers).
- Wires the appliance’s producers and consumers to the customer’s bootstrap servers.
- Injects the customer’s credentials as secrets the services read at startup.
- Configures the security protocol and SASL mechanism the clients use.
What the customer takes on
When your customer brings their own Kafka, they own:- Cluster provisioning, broker sizing, and partition count planning.
- Topic creation, retention policy, compaction settings, and replication factor.
- ACL configuration so the appliance principal can read and write the topics it needs.
- Backup, mirror topology (MirrorMaker 2, Confluent Replicator), and cross-region replication.
- Patching, version upgrades, and major-version migrations. The customer’s broker version must remain compatible with your client library’s protocol version.
- High availability, controller quorum, and disaster recovery.
- Monitoring, alerting, and incident response for the brokers, controllers, and schema registry.
What stays your responsibility
- All application-level concerns: topic naming, schema design, producer/consumer correctness, idempotency, ordering guarantees, transactional semantics.
- Your services continue to be observable through Tensor9’s normal mechanisms.
- Operations commands that operate on the appliance’s services still work normally. Operations commands cannot reach into your customer’s Kafka brokers.
Deployment notes
Confluent Cloud is the path of least friction for customers without an existing Kafka operations team. The appliance reaches the cluster over the public internet (or private peering if the customer enables it), authenticated by SASL/PLAIN with API keys. AWS MSK (including MSK Serverless) is common for customers who centralize Kafka inside AWS. IAM-auth (AWS_MSK_IAM SASL mechanism) is preferred for least-privilege; SASL/SCRAM is also supported.
Self-hosted Strimzi is common for customers running Kubernetes who want Kafka native to their cluster. Redpanda is a drop-in Kafka-API alternative with simpler operations (single-binary, no Zookeeper).
Authentication and rotation
SASL credentials, mTLS client cert + key, and CA cert are stored as Customer-Supplied Secrets - Tensor9 has no visibility into the underlying values. The appliance reads them at startup. Rotation depends on the SASL mechanism:- SASL/PLAIN, SASL/SCRAM: rotate the password in the cluster’s auth config and update the secret in the customer’s secret store; restart the affected services so they reconnect.
- OAUTHBEARER: the appliance fetches tokens from the customer’s IdP on each connection; rotation is handled by the IdP.
- AWS_MSK_IAM: the appliance assumes a customer-supplied IAM role and the underlying STS token refreshes automatically (no service restart needed).
- mTLS: rotate the client cert + key in the customer’s secret store and restart so the new identity is presented on reconnection.