openCenter Managed Kafka
A secure, managed Apache Kafka service for private, hybrid, and air-gapped environments. Built on the Strimzi operator ecosystem with repeatable deployment, managed operations, and a clear expansion path for future streaming capabilities. Standard Apache Kafka with a managed operating model — not a proprietary alternative.
What you get
- Standard Apache Kafka as a managed service — real Kafka, not a proprietary alternative.
- Managed provisioning and operations — openCenter handles deployment, lifecycle, and operational workflows.
- High availability deployment patterns — production-ready HA deployment options for supported infrastructure.
- Dedicated deployment options — stronger isolation for regulated or higher-risk environments.
- Encryption in transit — secure-by-default service posture with TLS for all communication.
- Authentication and authorization — controlled access for Kafka users and client applications (SASL/SCRAM, mTLS, OAuth2/OIDC).
- Observability and lag visibility — better operational visibility with Prometheus, Grafana, and Kafka Exporter.
- Air-gapped deployment support — works in disconnected and tightly controlled environments.
- Compliance-oriented operating model — supports customers that need controlled operations and evidence-oriented practices.
- Change windows and maintenance workflows — supports managed upgrades and controlled maintenance.
What Is Not Included in the Base Offer
To keep the offering clear and supportable, the base service does not currently include:
- ✗Serverless Kafka
- ✗Native autoscaling
- ✗Built-in schema registry
- ✗Unlimited connector support
- ✗Managed runtime for Kafka Streams applications
Schema registry, governance, and curated connectors are planned as future add-ons after the base service stabilizes.
Where It Fits Best
openCenter Managed Kafka is a strong fit for:
Enterprise Platform Teams
Standardizing event streaming for internal application teams without taking on full broker operations burden.
Regulated Organizations
Need Kafka in private cloud or disconnected environments with controlled operations and evidence-oriented practices.
Hybrid Cloud Customers
Cannot rely on a SaaS-managed Kafka control plane and need private or hybrid deployment options.
Modernization Programs
Adopting event-driven integration patterns with a credible operating model and clear support boundaries.
Four Pillars
Deploy, upgrade, and scale through Git
Kafka clusters, topics, users, and ACLs are declared in Git and reconciled by FluxCD. No manual broker configuration. No SSH. Upgrades are a version bump in a YAML file with automatic rolling restarts and health checks.
Broker metrics, consumer lag, and partition health
Prometheus exporters, Grafana dashboards, and alerting rules ship with the blueprint. Consumer lag, under-replicated partitions, ISR shrink, and disk usage are monitored before you produce your first message.
TLS, SASL, ACLs, and network isolation
Inter-broker TLS, SASL authentication, topic-level ACLs, and NetworkPolicies are configured out of the box. Secrets are SOPS-encrypted in Git and decrypted at reconciliation time. No plaintext credentials anywhere.
Backup, recovery, and capacity planning
Topic configuration backup, partition reassignment tooling, and tested recovery runbooks. Capacity planning based on actual throughput metrics, not guesswork. Velero integration for disaster recovery of operator state.
Capabilities
The Streaming Services blueprint is broader than a single Kafka cluster. It covers the full streaming surface area so you can grow without changing your operating model.
Kafka Clusters
Multi-broker clusters managed by Strimzi operator with KRaft mode, node pools, rolling upgrades, and rack awareness.
Kafka Connect & MirrorMaker 2
Connect clusters with plugin management via OCI artifacts, and MirrorMaker 2 for cross-cluster replication with connector lifecycle controls.
HTTP & MQTT Bridges
REST API for Kafka operations and MQTT 3.1.1 ingestion bridge with topic mapping rules for edge device integration.
Strimzi Ecosystem Components
The Streaming Services blueprint is built on the Strimzi ecosystem, providing a complete Kubernetes-native platform for Apache Kafka and related components:
- Strimzi Kafka Operator: Core control plane with Cluster, Topic, User, and Entity operators
- Kafka Access Operator: Service Binding-style Secrets for simplified app connectivity
- Kafka Bridge: HTTP 1.1 REST API for producing, consuming, and topic management
- MQTT Bridge: One-way MQTT 3.1.1 to Kafka ingestion with topic mapping rules
- Drain Cleaner: Admission webhook for safe node draining during maintenance
- Kafka OAuth: OAuth2/OIDC authentication with Keycloak authorization integration
- Quotas Plugin: Aggregate broker quotas and storage-aware throttling
- Config Provider: Kubernetes Secret/ConfigMap integration for externalized config
All components are operator-managed, GitOps-ready, and include supply chain security artifacts (cosign signatures, SBOMs).
Platform Capabilities
Strimzi on openCenter provides 14 standard Kafka platform capabilities out of the box, with 4 partially supported and 1 requiring external integration:
✅ Fully Supported (14)
Kafka brokers, provisioning, HA, encryption, auth, Connect, replication, observability, IaC, air-gap, operational clarity
⚠️ Partial Support (4)
Cluster models, autoscaling, SLA eligibility, incident response
❌ Not Included (1)
Schema Registry (external deployment required)
✅ Fully Supported Capabilities
▸Runs Apache Kafka Brokers
What it means: The platform runs genuine Apache Kafka broker processes, not a proprietary reimplementation.
Implementation: Strimzi Kafka Operator deploys Apache Kafka brokers via Kubernetes CRDs. Supports all standard Kafka versions with full protocol compatibility. No vendor lock-in.
Why it matters: Ensures compatibility with the entire Kafka ecosystem and avoids vendor lock-in.
▸Fully Managed Provisioning / Broker Ops
What it means: The platform handles broker lifecycle operations without manual intervention.
Implementation: Cluster Operator manages Kafka cluster lifecycle via declarative CRs. Rolling upgrades with health checks, node pools for role separation, rack awareness, storage management with PVC retention, and operator HA with leader election.
Why it matters: Eliminates manual SSH-based broker management and ensures consistent deployment patterns.
▸High Availability / Multi-Zone
What it means: Supports deploying Kafka clusters across multiple availability zones with automatic failover.
Implementation: Rack awareness distributes replicas across Kubernetes topology zones. PVC retention prevents data loss. Cluster Operator HA with leader election. KRaft controller scaling supports no-downtime scaling. Drain Cleaner coordinates node draining.
Why it matters: Ensures Kafka remains available during zone failures and infrastructure disruptions.
▸Encryption in Transit / At Rest
What it means: Data is encrypted while moving between brokers/clients and while stored on disk.
Implementation: TLS for inter-broker and client connections with configurable protocols/cipher suites. Alternative bootstrap names for TLS hostname verification. At-rest encryption via Kubernetes storage (PVC encryption via storage class).
Why it matters: Protects sensitive data from network sniffing and unauthorized disk access. Required for compliance (PCI-DSS, HIPAA, SOC 2).
▸AuthN / AuthZ (SASL/mTLS/OAuth/ACL)
What it means: Multiple authentication mechanisms and fine-grained authorization controls.
Implementation: SASL/SCRAM, mTLS, OAuth2/OIDC with Keycloak integration. Kafka ACLs via KafkaUser CR with User Operator. Per-user quotas. Custom authorizer support. Keycloak Authorization Services with centrally managed authz rules.
Why it matters: Enables multi-tenant security, compliance with least-privilege principles, and enterprise identity integration.
▸Kafka Connect / Managed Connectors
What it means: Kafka Connect for integrating external systems via source and sink connectors.
Implementation: KafkaConnect CR for operator-managed Connect clusters. KafkaConnector CR for connector lifecycle. Plugin artifacts from OCI images. Connector state control (stop/pause/resume). Config Provider integration for Kubernetes Secrets/ConfigMaps.
Why it matters: Simplifies integration with databases, object storage, and message queues without custom code.
▸Replication / DR Primitives
What it means: Tools for cross-cluster replication and disaster recovery.
Implementation: KafkaMirrorMaker2 CR for operator-managed MirrorMaker2. Connector lifecycle controls with state management. Task restart annotations. Active-active and active-passive patterns. Automatic offset translation.
Why it matters: Enables disaster recovery, data center migration, and geo-replication for global applications.
▸Observability (lag/metrics/log export)
What it means: Visibility into broker health, consumer lag, partition metrics, and operational logs.
Implementation: Prometheus monitoring with pre-wired exporters. Kafka Exporter for consumer lag with Grafana dashboards. Quotas plugin metrics. OAuth metrics enablement. Metrics Reporter for Kafka server/client components.
Why it matters: Enables proactive monitoring, alerting, capacity planning, and troubleshooting before issues impact users.
▸IaC / APIs (Terraform/CLI/API)
What it means: Infrastructure-as-code workflows and programmatic management via APIs or CLI tools.
Implementation: Kubernetes CRDs as IaC primitives (Kafka, KafkaTopic, KafkaUser, KafkaConnect, etc.). Helm chart for operator installation. GitOps-ready with FluxCD/ArgoCD. HTTP Bridge REST API with OpenAPI-defined endpoints for produce/consume/admin operations.
Why it matters: Enables version-controlled infrastructure, automated deployments, and CI/CD integration.
▸Air-gapped / Disconnected Support
What it means: Can be deployed in environments without internet access.
Implementation: No external dependencies. All container images available for local registry mirroring. Cosign-signed images with SBOM for verification. Helm chart can be packaged offline. CRDs bundled with operator.
Why it matters: Enables deployment in highly secure environments (government, financial, healthcare) where internet access is prohibited.
▸Compliance / Audit Controls
What it means: Audit logging, policy enforcement, and evidence collection for compliance requirements.
Implementation: Cosign signatures for all core operator images (keyless since 0.49). SBOM in SPDX-JSON + Syft format with signed SBOMs. Quotas plugin with aggregate per-broker quotas and storage-aware throttling. Keycloak integration for centralized authorization with audit trail.
Why it matters: Meets regulatory requirements (SOC 2, ISO 27001, PCI-DSS) and provides evidence for security audits.
▸Operational Scope Clarity
What it means: Clear definition of what the platform team manages vs. what application teams manage.
Implementation: Platform team manages Cluster/Topic/User/Access Operators, operator lifecycle, and Kubernetes infrastructure. Application teams manage topic/user/connector definitions via CRs in their namespace, application code, and schema management.
Why it matters: Prevents confusion, reduces operational friction, and enables self-service for application teams within guardrails.
▸Procurement: “Who Owns What?” Clarity
What it means: Clear understanding of ownership, support, and escalation paths.
Implementation: openCenter platform team owns Kubernetes infrastructure, Strimzi operator lifecycle, and GitOps workflows. Application teams own topic/user/connector definitions and application code. Strimzi (open source) provides operator code and CRDs. No vendor SLA from Strimzi; SLA comes from openCenter platform agreement.
Why it matters: Ensures clear accountability, prevents support gaps, and sets realistic expectations for SLA and incident response.
▸Procurement: Change Windows & Maintenance Policy
What it means: Defined processes for upgrades, maintenance, and change management with minimal disruption.
Implementation: Rolling upgrades via version bump in Kafka CR with health checks. Helm upgrade requires manual CRD upgrade. Drain Cleaner coordinates node draining with Strimzi rolling updates. GitOps-driven change management with declarative desired state and rollback via Git revert.
Why it matters: Enables predictable maintenance windows, reduces downtime, and provides rollback mechanisms for failed changes.
⚠️ Partially Supported Capabilities
▸Cluster Model Options (serverless/dedicated/etc.)
What it means: Different cluster deployment models with different cost/performance trade-offs.
Supported: Dedicated clusters with flexible node pools, resource allocation, and storage customization.
Not Supported: Serverless model (no pay-per-request or auto-pause). Shared multi-tenant clusters (each cluster is isolated).
Why it matters: Serverless models reduce costs for low-traffic workloads. Strimzi requires dedicated cluster planning.
▸Autoscaling
What it means: Automatically scales broker count or resources based on load.
Supported: Manual scaling via node pool replica count adjustment. Cruise Control for optimization proposals and manual rebalancing. Storage scaling via JBOD volumes.
Not Supported: Automatic broker scaling (no HPA support). Self-healing rebalancing (Cruise Control rebalances are manual). Auto-scaling based on metrics.
Why it matters: Autoscaling reduces operational toil and optimizes costs. Strimzi requires capacity planning and manual intervention.
▸Procurement: SLA/SLO Eligibility
What it means: Service Level Agreements (uptime guarantees, response times) and Service Level Objectives.
HA Primitives Provided: Operator HA with leader election, rack awareness, PVC retention, Drain Cleaner, probes, rolling upgrades.
SLA Considerations: No Strimzi SLA (open-source). Platform SLA depends on openCenter platform agreement. Shared responsibility between platform team and app teams. Monitoring required for SLA measurement.
Why it matters: SLA commitments require clear accountability. Strimzi provides technical foundation; SLA comes from platform agreement.
▸Procurement: Incident Response & Escalation
What it means: Defined processes for incident detection, triage, escalation, and resolution.
Monitoring Primitives Provided: Prometheus/Grafana for metrics, Kafka Exporter for consumer lag, operator logs, Kubernetes events, Alertmanager integration.
Incident Response: Platform team handles operator health and infrastructure. Application teams handle application-level issues. Strimzi community support (best-effort). No commercial support from Strimzi; escalation follows openCenter support model.
Why it matters: Incident response speed impacts downtime. Strimzi provides observability tools; escalation depends on platform support agreement.
❌ Not Supported Capabilities
▸Schema Registry
What it means: A centralized service for managing, validating, and evolving message schemas with compatibility enforcement.
Not Included: Schema Registry is not part of the Strimzi ecosystem. Strimzi focuses on Kafka core; schema management is external.
External Options: Confluent Schema Registry (commercial or open-source), Apicurio Registry (open-source, Red Hat supported), AWS Glue Schema Registry, or custom deployment.
Integration: Schema Registry can be deployed in the same Kubernetes cluster. Kafka clients configured to use external Schema Registry URL. No special Strimzi integration required.
Why it matters: Schema Registry prevents breaking changes and enables schema evolution. Plan for separate deployment if schema validation is required.
This is a self-managed platform: openCenter provides the infrastructure and GitOps workflows, Strimzi operators manage Kafka lifecycle. SLA and support come from your openCenter platform agreement, not from Strimzi directly.