Redpanda BYOC requirements checklist for security review (IAM, networking, private connectivity, logging)

Security teams ask the same question when they hear “Bring Your Own Cloud”: what exactly runs where, and how do we keep strict control? With Redpanda BYOC, the answer is simple but non‑negotiable: your data and clusters live in your cloud; Redpanda operates the control plane and receives only the minimal telemetry needed to keep the service healthy and auditable.

This checklist walks you through the core BYOC requirements for a security review across IAM, networking, private connectivity, and logging so you can move from architecture diagram to approved deployment.

The Quick Overview

What It Is: Redpanda BYOC is a managed Redpanda service where the data plane (brokers, storage, network) runs entirely in your cloud account, while Redpanda provides a managed control plane, SRE operations, and upgrades.
Who It Is For: Platform, security, and data engineering teams that need Kafka‑compatible streaming and an agentic data plane, but must retain full control over infrastructure, data residency, and network boundaries.
Core Problem Solved: You get the operational simplicity of “managed Kafka” and the governance Redpanda is known for, without giving up data sovereignty or letting another vendor own your underlying infrastructure.

How It Works

Redpanda BYOC splits responsibilities between your cloud environment and Redpanda’s management plane:

You provision and own the cloud environment (VPC, subnets, security groups, KMS, IAM).
Redpanda deploys and operates the Redpanda clusters and control agents into that environment, using least‑privilege IAM.
Redpanda receives specific telemetry and control signals (Grafana metrics, system logs, HTTP Admin) to monitor, debug, and orchestrate the service—never your application payloads.

From a security review perspective, it’s about three phases: prepare IAM, lock down networking, and wire up observability and audit.

Prepare IAM & Roles:
Define cloud IAM roles and policies so Redpanda can deploy and manage clusters with least privilege—no more, no less.
Harden Networking & Connectivity:
Place Redpanda in private subnets, control inbound/outbound paths, and configure whichever private connectivity model your security team requires (VPC peering, PrivateLink, VPN, or internal-only).
Enable Logging, Telemetry & Audit:
Confirm which logs and metrics leave your environment (Grafana telemetry, syslog/journalctl, HTTP Admin), where they land, and how they plug into your SIEM and audit requirements.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
BYOC Data Plane	Runs Redpanda brokers and storage fully inside your AWS/GCP/Azure account	Full control over infrastructure and data residency; simplifies compliance
Managed Control Plane & SRE	Redpanda manages upgrades, scaling, and healing via a secure control plane	Offloads day‑2 ops while preserving strong security and operational governance
Enterprise Security Controls	Fine‑grained ACLs, TLS, RBAC, OIDC, and audit logging	Govern every action before it happens; meet enterprise auth and audit standards

IAM Requirements Checklist

Redpanda BYOC relies on a clear, auditable IAM story. Use this checklist to align with your security review.

1. Identity & Access Model

Dedicated IAM roles for Redpanda BYOC
- Create one or more roles for Redpanda’s deployment and operations automation.
- Apply least‑privilege access to only the resources required (compute, storage, logging, networking).
Separation of duties
- Use separate roles for:
  - Cluster provisioning / lifecycle management
  - Day‑to‑day operations / support access
- Allow your security team to review and approve Redpanda‑provided IAM policy documents.
Federated access for humans
- Require your operators to use SSO + RBAC inside Redpanda Console.
- Optionally integrate with OIDC for identity and “on‑behalf‑of” authorization for agentic workloads.

2. Permissions for BYOC Operations

These categories are typically required (exact policy templates come from Redpanda):

Compute
- Permission to provision and manage node groups/VMs/instances that host Redpanda brokers and helper services.
Storage
- Permission to create and access storage resources for:
  - Redpanda logs and tiered storage
  - Internal checkpoints and snapshots
- Encryption with your own KMS keys if required.
Networking
- Permission to attach Redpanda nodes to your VPC, subnets, and security groups.
- Permission to manage required load balancers or private endpoints, depending on your connectivity choice.
Logging & Monitoring
- Permission to write telemetry to your logging and metrics services (e.g., CloudWatch/Stackdriver/Log Analytics or Prometheus endpoints).
- Permission to access and ship:
  - Grafana telemetry (CPU, disk, usage)
  - System logs (syslog/journalctl) for debugging
  - HTTP Admin interface for command and control

Networking Requirements Checklist

You own the network surface; Redpanda operates inside it. The core goal is: private-by-default, explicit where public is allowed.

1. VPC & Subnet Layout

Dedicated VPC or well‑segmented shared VPC
- Place Redpanda brokers in private subnets with no direct internet routing where possible.
- Keep a clear boundary between production, staging, and test environments.
Security groups / firewall rules
- Inbound access restricted to:
  - Application services that must talk to Redpanda (consumers, producers, AI agents).
  - Approved admin endpoints (e.g., jump hosts, bastion, or VPN).
- Outbound access restricted to:
  - Managed control plane endpoints
  - Logging/metrics destinations
  - Any approved external systems (e.g., connector targets)

2. Control Plane Connectivity

Outbound‑only control plane where possible
- Allow Redpanda BYOC agents to establish outbound connections from your cloud to Redpanda’s control plane over TLS.
- Block unsolicited inbound connections from the public internet.
IP allowlists and DNS control
- Maintain allowlists for Redpanda control plane IP ranges or hostnames.
- Ensure DNS resolution for Redpanda management endpoints is routed appropriately.

Private Connectivity Checklist

You decide how applications reach Redpanda in your cloud; BYOC supports multiple patterns.

1. Internal‑Only Access

Only internal services can reach Redpanda
- Enforce that producers/consumers must live inside:
  - The same VPC, or
  - Peered VPCs / on‑prem through VPN/Direct Connect
- No public listeners unless explicitly required.

2. VPC Peering / Private Endpoints

VPC Peering or Transit Gateway
- Set up peering between the Redpanda BYOC VPC and any application VPCs.
- Ensure route tables allow traffic to Redpanda broker endpoints.
PrivateLink / Service Endpoints (where available)
- Optionally expose Redpanda via cloud‑native private endpoints:
  - Gives you private IP access from many VPCs without broad peering.
  - Reduces the blast radius if an endpoint must be locked down quickly.

3. Hybrid / On‑Prem Connectivity

VPN or Direct Connect / ExpressRoute / Interconnect
- Use your existing private network links to connect on‑prem apps to Redpanda.
- Ensure latency and throughput targets meet your streaming SLOs.

Logging, Telemetry & Audit Checklist

Redpanda BYOC is designed to be observable and auditable without exfiltrating your business data. Security reviewers should confirm what leaves the environment and how it’s used.

1. Telemetry to Redpanda

Redpanda receives specific operational data from your BYOC environment:

Grafana telemetry (metrics)
- CPU, disk, and usage metrics from Redpanda clusters.
- Used for health checks, scaling decisions, capacity planning.
System logs (syslog/journalctl)
- Node‑level logs for debugging and incident response.
- No application payloads; limited to system and service events.
HTTP Admin access for command and control
- Secure, authenticated access to Redpanda’s admin surface for:
  - Configuration changes
  - Rolling upgrades
  - Recovery operations

Security review focus:

Transport is TLS‑encrypted.
Access is limited to Redpanda automation and SRE team.
Operations are logged and traceable.

2. In‑Cluster Security & Audit

TLS encryption in transit
- Enable TLS between clients and Redpanda brokers.
- Optionally use your own certificates and CA.
Fine‑grained ACLs
- Lock down topics, consumer groups, and transactional APIs.
- Use ACLs to ensure agents and applications only see the topics they are authorized for.
Role‑based access control (RBAC)
- Configure RBAC for Redpanda Console and any admin APIs.
- Tie roles to SSO groups (e.g., SRE, Security, Data Platform) instead of individual users.
Audit logging
- Enable and ship audit logs to your SIEM.
- Cover:
  - Security events (logins, policy changes)
  - Administrative actions (topic creation, ACL changes)
  - Critical data‑plane operations (deletes, retention changes)

3. Observability Integration

Prometheus / OTEL integration
- Use built‑in Prometheus metrics to monitor cluster health and latency.
- Optionally export metrics via OpenTelemetry to your central observability stack.
Centralized log aggregation
- Forward broker logs, connector logs, and audit logs to:
  - Cloud‑native logging (CloudWatch, Stackdriver, etc.)
  - Your SIEM or log analytics platform
- Apply retention policies and access controls that match your compliance baselines.

Security Considerations & Best Practices

Data Sovereignty & Compliance

Redpanda BYOC is designed so data never leaves your cloud.
You choose region, cloud, and account structure to meet:
- Data residency requirements
- Industry standards (e.g., financial, healthcare, gaming)

Combine that with the ability to run in AWS, GCP, Azure, and even air‑gapped environments, and you get a path to governed streaming without surrendering sovereignty.

Governance for AI & Agents

BYOC isn’t just about streaming; it’s about supporting the Agentic Data Plane with strict guardrails:

Use OIDC identity and on‑behalf‑of authorization to bind AI agents to real user identities.
Apply tool‑level policies in front of topics and connectors:
- Filter, redact, or restrict data so agents only see what they should.
Keep a permanent record of agent actions via audit logs and streaming history:
- Replay sessions when something goes wrong.
- Prove who did what, when, and with which tools.

When agents will use and change production data, this is the difference between safe automation and chaos.

Limitations & Considerations

Cloud IAM & networking complexity:
BYOC gives you control, but that means you own VPC, IAM, and private connectivity design. Plan for collaboration between platform, security, and networking teams early.
Telemetry scope is fixed to operational data:
Redpanda BYOC expects access to Grafana telemetry, system logs, and HTTP Admin. If your organization bans all outbound telemetry, you’ll need to work with Redpanda to find an acceptable pattern that still meets SRE and support requirements.

Ideal Use Cases

Best for regulated or sensitive workloads: Because you retain full control over infrastructure, network boundaries, and encryption keys while still getting a managed, Kafka‑compatible streaming backbone.
Best for high‑scale, latency‑sensitive event systems: Because Redpanda’s single‑binary engine and BYOC deployment keep brokers close to your apps and data, delivering predictable performance without managed‑service “noisy neighbor” issues.

Pricing & Plans

Specific pricing for Redpanda BYOC depends on your deployment size, cloud environment, and support requirements. In general, you can think of options along these lines:

BYOC Standard: Best for teams needing a production‑grade, Kafka‑compatible streaming platform with managed operations, SRE support, and standard cluster sizing.
BYOC Enterprise: Best for organizations with strict compliance, 24x7 SRE coverage, custom SLAs, multi‑region architectures, and advanced security requirements (e.g., air‑gapped, dedicated control paths).

For an accurate quote and detailed architecture review, you’ll want to engage directly with Redpanda.

Frequently Asked Questions

What data leaves my cloud environment in a Redpanda BYOC deployment?

Short Answer: Only operational telemetry and control signals—not your application messages or topic data.

Details:
Redpanda BYOC requires access to:

Grafana telemetry like CPU, disk, and usage metrics for monitoring and capacity management.
System logs (syslog/journalctl) to debug node‑level issues and support incident response.
HTTP Admin for authenticated command and control of the clusters (e.g., upgrades, configuration changes).

All of this travels over encrypted channels and is scoped to Redpanda’s operations team and automation. Your Kafka topics, messages, and historical data remain in your cloud account and subject to your own access controls, retention policies, and encryption.

Can I enforce my own IAM, RBAC, and logging policies on top of Redpanda BYOC?

Short Answer: Yes. You keep full control of IAM and can layer your own RBAC, logging, and SIEM integrations on top of BYOC.

Details:
Because Redpanda runs inside your cloud account, you:

Define the IAM roles Redpanda uses and the scope of their permissions.
Control how Redpanda clusters are exposed via VPC, peering, VPN, or private endpoints.
Apply your own:
- RBAC policies to the Redpanda Console via SSO group mapping.
- Network policies via security groups and firewalls.
- Audit and logging rules by routing Redpanda logs and audit events into existing SIEMs.

Redpanda adds its own security model—TLS, ACLs, RBAC, audit logging—on top of your cloud controls, giving you layered defense and governance‑before‑action.

Summary

Redpanda BYOC gives you Kafka‑compatible streaming and an agent‑ready data plane without handing over your infrastructure or data. Your cloud, your VPCs, your IAM; Redpanda brings the engine, the SRE runbooks, and the operational guardrails.

For a security review, focus on four pillars:

IAM: Dedicated, least‑privilege roles for Redpanda operations.
Networking: Private subnets, restricted security groups, and tight control plane egress.
Private Connectivity: VPC peering, private endpoints, or VPN/Direct Connect for internal‑only access.
Logging & Telemetry: Clearly scoped telemetry (Grafana metrics, system logs, HTTP Admin), plus your own TLS, ACLs, RBAC, and audit logging.

When those boxes are checked, you get a governed, observable streaming backbone that’s ready for modern agentic workloads—and compliant enough for your toughest auditors.

Next Step

Get Started