diff --git a/modules/get-started/pages/whats-new-cloud.adoc b/modules/get-started/pages/whats-new-cloud.adoc index c7ec6995..e9d6add5 100644 --- a/modules/get-started/pages/whats-new-cloud.adoc +++ b/modules/get-started/pages/whats-new-cloud.adoc @@ -8,6 +8,12 @@ This page lists new features added to Redpanda Cloud. == November 2025 +=== User impersonation + +BYOC and Dedicated clusters now support unified authentication and authorization between the Redpanda Cloud UI and Redpanda with xref:security:cloud-authentication.adoc#user-impersonation-beta[user impersonation]. This means you can authenticate to fine-grained access within Redpanda using the same credentials you use to authenticate to Redpanda Cloud. + +With user impersonation, the topics users see in the UI are identical to what they can access with the Cloud API or `rpk`, ensuring consistent permissions across all interfaces and clear auditing of data plane user actions. + === Redpanda Connect updates Redpanda Connect provides a simplified xref:develop:connect/connect-quickstart.adoc[quickstart] experience in the UI that helps you to start building data pipelines. The quickstart wizard creates pipelines to stream data into and out of Redpanda, populating the required YAML configuration automatically. @@ -26,6 +32,18 @@ The xref:manage:terraform-provider.adoc[Redpanda Terraform provider] now support == October 2025 +=== User impersonation: beta + +BYOC and Dedicated clusters now support unified authentication and authorization between the Redpanda Cloud UI and Redpanda with xref:security:cloud-authentication.adoc#user-impersonation-beta[user impersonation]. This means you can authenticate to fine-grained access within Redpanda using the same credentials you use to authenticate to Redpanda Cloud. + +With user impersonation, the topics users see in the UI are identical to what they can access with the Cloud API or `rpk`, ensuring consistent permissions across all interfaces. This glossterm:beta[] feature provides clear auditing of data plane user actions. + +=== Remote read replicas: GA + +xref:get-started:cluster-types/byoc/remote-read-replicas.adoc[Remote read replicas] are now generally available (GA) for BYOC clusters on AWS and GCP. This feature allows you to create read-only topics that mirror a topic on a different cluster, providing greater flexibility and scalability for your data streaming needs. + +== October 2025 + === Remote MCP: beta Deploy managed MCP servers directly inside your Redpanda Cloud cluster with xref:ai-agents:mcp/remote/overview.adoc[Remote MCP]. Unlike the Redpanda Cloud MCP Server, Remote MCP servers run within your cluster and can process data streams, generate synthetic data, and publish directly to Redpanda topics. diff --git a/modules/security/pages/cloud-authentication.adoc b/modules/security/pages/cloud-authentication.adoc index a2f03756..d04ecf11 100644 --- a/modules/security/pages/cloud-authentication.adoc +++ b/modules/security/pages/cloud-authentication.adoc @@ -2,23 +2,26 @@ :description: Learn about Redpanda Cloud authentication. :page-toclevels: 3 -Redpanda Cloud provides secure authentication for both users accessing the platform and services connecting to your clusters. +Redpanda Cloud uses authentication to verify who can access your clusters and perform actions. + +* *User authentication*: How people access the Redpanda Cloud UI and manage resources +* *Service authentication*: How applications and services connect to your Redpanda clusters == User authentication -Redpanda provides user authentication to your Redpanda organization through email/password or single sign-on. +Redpanda provides user authentication to your Redpanda organization through email/password or single sign-on (SSO) with OIDC-based identity provider (IdP). -=== Email +=== Email/password -Redpanda Cloud can authenticate users with emails and passwords. Passwords are hashed (a one-way function that makes the original value unrecoverable, and effectively encrypted) and salted at rest using https://en.wikipedia.org/wiki/Bcrypt[bcrypt^]. +Passwords are hashed (a one-way function that makes the original value unrecoverable, and effectively encrypted) and salted at rest using https://en.wikipedia.org/wiki/Bcrypt[bcrypt^]. === Single sign-on -Redpanda Cloud can authenticate users with single sign-on (SSO) to an OIDC-based identity provider (IdP). Redpanda integrates with any OIDC-compliant IdP that supports discovery, including <>, <>, Auth0, Active Directory Federation Services (AD-FS), and JumpCloud. After SSO is enabled for an organization, new users in that organization can authenticate with SSO. +Redpanda integrates with any OIDC-compliant IdP that supports discovery, including <>, <>, Auth0, Active Directory Federation Services (AD-FS), and JumpCloud. After SSO is enabled for an organization, new users in that organization can authenticate with SSO. -You must integrate your IdP with Redpanda Cloud to use SSO. On the *Users* page, users with admin permission see a *Single sign-on* tab and can add connections for up to two different IdPs. Enter the client ID, client secret, and discovery URI for the IdP. (See your IdP documentation for these values. The discovery URI may be called something different, like the well known URL or the `issuer_url`.) +You must integrate your IdP with Redpanda Cloud to use SSO. On the *Users* page, users with the admin permissions see a *Single sign-on* tab and can add connections for up to two different IdPs. Enter the client ID, client secret, and discovery URI for the IdP. (See your IdP documentation for these values. The discovery URI may be called something different, like the well known URL or the `issuer_url`.) -By default, the connection is added in a disabled state. Edit the connection to enable it. You can choose to enable auto-enroll in the connection, which provides new users signing in from that IdP access to your Redpanda organization. When you enable auto-enroll, you select to assign a read, write, or admin role to users who log in with that IdP. Set up is different for most IdPs. +By default, the connection is added in a disabled state. Edit the connection to enable it. You can choose to enable auto-enroll in the connection, which provides new users signing in from that IdP access to your Redpanda organization. When you enable auto-enroll, you select to assign a Reader, Writer, or Admin role to users who log in with that IdP. Set up is different across IdPs. NOTE: Before you can delete an SSO connection, an admin must manually delete all users associated with that connection. @@ -106,20 +109,56 @@ Administrators can require MFA for all users in an organization. * *TOTP code not accepted:* Ensure the code hasn't expired and that your phone's time is set automatically; time drift can cause invalid codes. * *Remembered device prompts again:* The 30-day trust is device- and browser-specific. Clearing cookies, switching browsers, or using a new device requires re-verification. +=== User impersonation + +include::shared:partial$feature-flag.adoc[] + +BYOC and Dedicated clusters support unified authentication and authorization between the Redpanda Cloud UI and Redpanda with user impersonation. With user impersonation enabled, the topics and resources users see in the UI match exactly what they can access with the Cloud API or `rpk`. You can use the same credentials to authenticate to both Redpanda Cloud and the underlying Redpanda cluster, with consistent permissions across all interfaces. This ensures accurate audit logs and unified identity enforcement across all client applications, including the Cloud UI. + +* *Without user impersonation*: Redpanda Cloud uses a static service account to access your cluster. All UI requests appear to come from this generic admin user. +* *With user impersonation*: Redpanda Cloud uses your individual user credentials and evaluates permissions using glossterm:ACL[,access control lists (ACLs)] and glossterm:RBAC[,role-based access control (RBAC)] in the data plane. Each user sees only the resources they have permission to access. + +To enable user impersonation: + +. Go to the *Cluster settings* page and select the option to enable user impersonation. +. Configure permissions for your users on the cluster *Security* page using ACLs or RBAC roles. + +[IMPORTANT] +==== +After enabling user impersonation: + +* *Admin users* continue to have full access as before +* *Reader and Writer users* will lose access to the cluster until you explicitly grant them permissions through ACLs or RBAC roles on the *Security* page + +Plan to configure user permissions before or immediately after enabling this feature to avoid access disruption. +==== + == Service authentication -Each Redpanda Cloud data plane runs its own dedicated agent, -which authenticates and connects against the control plane over a single TLS 1.2 -encrypted TCP connection. +Your applications and tools need to authenticate when connecting to Redpanda APIs. Redpanda Cloud supports different authentication methods depending on which API you're using and your cloud provider. + +* *SASL* (Simple Authentication and Security Layer): Username and password authentication over encrypted connections +* *mTLS* (Mutual TLS): Certificate-based authentication where both client and server verify each other's identity +* *Basic authentication*: Username and password sent in HTTP headers over encrypted connections + +NOTE: mTLS authentication is supported on AWS and GCP clusters only. Azure clusters currently support SASL and basic authentication only. -Different Redpanda APIs support different authentication methods: +=== Authentication methods by API -* Kafka API: Redpanda Cloud supports both SASL (over TLS 1.2) and <> authentication for Kafka clients connecting to Redpanda clusters over the TCP endpoint or listener. -* HTTP Proxy and Schema Registry: Redpanda Cloud supports HTTP Basic Authentication (encrypted over TLS 1.2) and <> for client authentication. +Different APIs support different authentication methods: -For AWS and GCP, you can simultaneously enable mTLS and SASL for Kafka API, and mTLS and Basic authentication for the HTTP APIs (HTTP Proxy and Schema Registry). If you enable both mTLS and SASL, Redpanda creates two distinct listeners: an mTLS listener operating on one port and a SASL listener operating on a different port. +* *Kafka API*: Redpanda Cloud supports both SASL (over TLS 1.2) and <> authentication for Kafka clients connecting to Redpanda clusters over the TCP endpoint or listener. +* *HTTP Proxy API* and *Schema Registry API*: Redpanda Cloud supports HTTP basic authentication (encrypted over TLS 1.2) and <> for client authentication. + +For AWS and GCP, you can simultaneously enable mTLS and SASL for the Kafka API, and mTLS and basic authentication for the HTTP APIs (HTTP Proxy and Schema Registry). + +When you enable both authentication methods, Redpanda creates separate listeners: + +* One mTLS listener on a specific port +* One SASL/basic authentication listener on a different port + +This allows clients to choose which authentication method to use when connecting. -.Redpanda API authentication methods [%collapsible] |=== |Cloud provider |API |Supported authentication methods @@ -135,12 +174,12 @@ a| ** SASL/PLAIN * mTLS -|HTTP Proxy +|HTTP Proxy API a| * Basic authentication * mTLS -|Schema Registry +|Schema Registry API a| * Basic authentication * mTLS @@ -156,12 +195,12 @@ a| ** SASL/PLAIN * mTLS -|HTTP Proxy +|HTTP Proxy API a| * Basic authentication * mTLS -|Schema Registry +|Schema Registry API a| * Basic authentication * mTLS @@ -173,15 +212,20 @@ a| ** SASL/SCRAM ** SASL/PLAIN -|HTTP Proxy +|HTTP Proxy API a| * Basic authentication -|Schema Registry +|Schema Registry API a| * Basic authentication |=== + +NOTE: Each Redpanda Cloud glossterm:data plane[] runs its own dedicated agent, +which authenticates and connects against the control plane over a single TLS 1.2 +encrypted TCP connection. + The following features use IAM policies to generate dynamic and short-lived credentials to interact with cloud provider APIs: @@ -194,27 +238,24 @@ xref:security:authorization/cloud-iam-policies.adoc[IAM policies] have constrain access or manage its own data plane-scoped resources, following the principle of least privilege. -== Configure service authentication - -Redpanda Cloud supports mTLS or SASL authentication for Kafka API, HTTP Proxy, and Schema Registry. +=== Configure service authentication -When you create a new cluster using the https://cloud.redpanda.com/[Cloud UI^], the cluster is enabled by default with SASL for Kafka API, and Basic authentication for HTTP Proxy and Schema Registry. +When you create a new cluster using the https://cloud.redpanda.com/[Cloud UI^], the cluster is enabled by default with SASL for the Kafka API and basic authentication for the HTTP Proxy API and Schema Registry API. === Requirements -NOTE: mTLS authentication is supported on AWS and GCP clusters only. +To configure service authentication using the Cloud API, you must have: -If you want to enable mTLS authentication: +* A service account in your Redpanda organization with administrative privileges +* Access to the link:/api/doc/cloud-controlplane/topic/topic-cloud-api-overview[Cloud API] -* You must use the Cloud API to create a new mTLS-enabled cluster. -* You must also use the Cloud API to update an existing cluster to switch to mTLS authentication for Kafka API. -* You can use the Cloud UI to update an existing cluster to switch to mTLS authentication for HTTP Proxy and Schema Registry only. -* To enable mTLS and SASL (or Basic authentication) simultaneously, you must use the Cloud API to create a new cluster or update an existing cluster. +==== Configuration methods by interface -To configure service authentication in your cluster using the Cloud API, you must have the following: - -* A service account in your Redpanda organization. You must have administrative privileges to create a service account. -* Access to the link:/api/doc/cloud-controlplane/topic/topic-cloud-api-overview[Cloud API] to enable mTLS or both SASL and mTLS. You use the service account to obtain an access token. You then make a request to the Control Plane API, passing the access token in the authorization header. +* *Cloud UI*: Create clusters with default SASL/basic authentication, or enable mTLS for HTTP Proxy and Schema Registry on existing clusters +* *Cloud API*: Required to: +** Create mTLS-enabled clusters +** Enable mTLS for the Kafka API on existing clusters +** Enable both mTLS and SASL/basic authentication simultaneously === Authenticate to the Cloud API @@ -252,7 +293,13 @@ Make sure to replace the following variables: For clusters with mTLS authentication, Redpanda creates a dedicated mTLS-enabled listener for each API service (Kafka API, HTTP Proxy, or Schema Registry) where you've enabled this authentication method. After you enable mTLS, <> and <>. -NOTE: If you enable mTLS authentication, you cannot disable it later. +[NOTE] +==== + +* mTLS authentication is supported on AWS and GCP clusters only. +* If you enable mTLS authentication, you cannot disable it later. +==== + ==== Create a new cluster with mTLS enabled @@ -260,7 +307,7 @@ NOTE: If you enable mTLS authentication, you cannot disable it later. . Make a link:/api/doc/cloud-controlplane/operation/operation-clusterservice_createcluster[`POST /v1/clusters`] request to create a new cluster with mTLS enabled. -NOTE: The following example enables mTLS for Kafka API. To enable mTLS for HTTP Proxy and Schema Registry, add the `http_proxy.mtls` and `schema_registry.mtls` fields to the request body. You can choose to enable mTLS for any combination of the three services. +NOTE: The following example enables mTLS for the Kafka API. To enable mTLS for HTTP Proxy and Schema Registry, add the `http_proxy.mtls` and `schema_registry.mtls` fields to the request body. You can choose to enable mTLS for any combination of the three services. .Show example request to enable mTLS for Kafka API [%collapsible] @@ -355,7 +402,7 @@ When the operation state is `COMPLETED`, you can <