Redpanda Access to Your Environment
When you run a Bring Your Own Cloud (BYOC) cluster, the data plane runs in your own cloud account and Redpanda operates it remotely. This page describes the access that operation requires: what the Redpanda Cloud agent can do in your account, what information reaches the Redpanda control plane, and what happens when an incident requires human intervention. Use it to answer vendor security review questions about Redpanda’s access to your environment. It applies to BYOC clusters on AWS, Azure, and GCP, including clusters where you bring your own VPC or VNet.
After reading this page, you will be able to:
-
Describe which resources the Redpanda Cloud agent can access in your cloud account and how its permissions are scoped
-
Explain what information crosses from your data plane to the Redpanda control plane
-
Explain how Redpanda controls emergency access to your data plane
Trust boundaries at a glance
Redpanda Cloud separates the systems that manage clusters from the clusters themselves. The control plane is a service that Redpanda runs in its own environment. The data plane is your cluster and its supporting infrastructure, and with BYOC it runs in your cloud account. Customer data never leaves the data plane.
The two planes exchange only what cluster management requires:
| Traffic | What it carries | Where it goes |
|---|---|---|
Data flows |
Messages produced to and consumed from topics |
Between your clients and your cluster |
Metadata flows |
Telemetry and cluster configuration, such as connection endpoints, cluster readiness, and status |
From the data plane to the control plane |
Control flows |
Control messages, such as cluster upgrades and configuration updates |
From the control plane to the data plane, pulled by the agent |
For diagrams of each flow, see Network Design and Ports. For the architecture behind the two planes, see BYOC Architecture.
What the Redpanda Cloud agent can do
The Redpanda Cloud agent is the software that operates your cluster from inside your account. When you provision a BYOC cluster with rpk cloud byoc <provider> apply, you grant IAM permissions to the agent, and those permissions authorize the agent alone. IAM policies do not apply to human users, and they do not grant Redpanda personnel access to your cluster or your data.
The agent’s permissions follow the principle of least privilege:
-
The agent accesses the cloud provider API to create and manage cluster resources, such as compute, networking, and object storage.
-
The agent creates dedicated IAM roles per workload, each with only the permissions that workload requires.
The agent pulls its work from the control plane. It authenticates with opaque, ephemeral tokens, then dequeues and applies the cluster specifications that provision, configure, and maintain your cluster.
For a full list of the permissions granted on a standard BYOC cluster, and why each is required, see the IAM policies for AWS, Azure, or GCP. For how agent authorization relates to the authorization models you configure for people and applications, see Choose an Authorization Model.
What the control plane receives
The control plane provisions, configures, and maintains clusters, and it needs cluster metadata to do that. Through metadata flows, the agent shares telemetry and cluster configuration with the control plane: connection endpoints, cluster readiness, and status.
Your streaming data takes a different path. Messages travel between your clients and your cluster, either through a public endpoint or through private connectivity such as VPC peering, AWS PrivateLink, Azure Private Link, or GCP Private Service Connect. Customer data never leaves the data plane.
How BYOVPC narrows access
If your policies require Redpanda to hold fewer permissions, create a Bring Your Own Virtual Private Cloud (BYOVPC) cluster (BYOVNet on Azure). You create the networking and security resources in advance, including the VPC or VNet, subnets, IAM roles, and storage resources, so the Redpanda agent does not create or change them. You also supply the identity that the agent uses and manage its permissions yourself, so the standard BYOC agent IAM policies do not apply.
The agent still deploys and operates the Redpanda cluster infrastructure in your account. It does that with the identity you supply, so its access is limited to the permissions you grant.
See BYOC for a comparison of the cluster variants, and see the shared responsibility model for what you manage versus what Redpanda manages.
Emergency access
Routine operations on your cluster are automated. The agent applies cluster specifications, upgrades, and configuration changes without human involvement, and Redpanda teams monitor clusters 24/7. Human access to your data plane is not part of routine operations.
Occasionally, incident responders use control flows to mitigate incidents when automated controls are insufficient. This emergency access path, called breakglass, is reserved for incident response:
-
A responder must create an access request that states the reason for access.
-
The request must be approved before the responder can connect.
-
The connection uses the outbound breakglass path listed in the network ports table.
To record authentication and Kafka resource access events on your own cluster for compliance and incident investigation, enable audit logging.