diff --git a/modules/networking/pages/configure-privatelink-in-cloud-ui.adoc b/modules/networking/pages/configure-privatelink-in-cloud-ui.adoc index b84c0847f..8d32ebb6b 100644 --- a/modules/networking/pages/configure-privatelink-in-cloud-ui.adoc +++ b/modules/networking/pages/configure-privatelink-in-cloud-ui.adoc @@ -70,10 +70,95 @@ include::networking:partial$private-links-aws-client-vpc-setup.adoc[] == Access Redpanda services through VPC endpoint -After you have enabled PrivateLink for your cluster, your connection URLs are available in the *How to Connect* section of the cluster overview in the Redpanda Cloud Console. +After you have enabled PrivateLink for your cluster, your connection URLs for the Kafka API, Schema Registry, HTTP Proxy, and Redpanda Console are available in the *How to Connect* section of the cluster overview in the Redpanda Cloud Console. include::networking:partial$private-links-access-rp-services-through-vpc.adoc[] +If you are connecting from a workstation outside the client VPC, see <>. + +[#access-redpanda-console-from-a-workstation] +== Access Redpanda Console from a workstation + +For a private BYOC cluster, Redpanda Console is exposed through the PrivateLink endpoint (or through another private route into the cluster VPC, such as VPC peering or a transit gateway), so a workstation outside the client VPC cannot resolve or reach the Console URL directly. To open Redpanda Console from a laptop, first connect the workstation to the client VPC over a VPN, then sign in to Redpanda Cloud Console and navigate to the cluster. + +Common VPN options: + +* AWS Client VPN attached to the client VPC (described below). +* A corporate VPN configured with a DNS forwarder that resolves `` against the client VPC's DNS resolver. +* An SSH SOCKS5 proxy through a bastion host in the client VPC. + +The following diagram shows the network path from a workstation, through the VPN, into the client VPC, and across PrivateLink to Redpanda Console: + +.... +Workstation + │ (public internet, OpenVPN tunnel, mutual TLS) + ▼ +AWS Client VPN endpoint ← AWS-managed; not PrivateLink + │ (workstation is now logically inside the client VPC) + ▼ +client VPC subnet + │ (VPC routing; DNS resolved via VPC resolver to a private IP) + ▼ +PrivateLink VPC endpoint ENI ← PrivateLink begins here + │ (AWS PrivateLink service network, not on the public internet) + ▼ +Redpanda cluster VPC → Console load balancer → Redpanda Console +.... + +The client VPN tunnel itself does not use PrivateLink. The VPN's role is to place the workstation logically inside the client VPC; the private connection to the cluster is always the PrivateLink endpoint. This is true regardless of how a client reaches the client VPC (client VPN, corporate VPN, peered network, transit gateway, SSH bastion, or an EC2 instance inside the VPC). + +=== Set up AWS Client VPN + +For full setup instructions, see the https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/cvpn-getting-started.html[AWS Client VPN Administrator Guide^]. The settings specific to Redpanda PrivateLink are: + +* *Authentication*: mutual certificate authentication. Generate a CA, server certificate, and client certificate; upload the server certificate and the CA certificate to AWS Certificate Manager (ACM). +* *Client IPv4 CIDR*: a CIDR between `/22` (minimum) and `/12` (maximum) that does not overlap the client VPC CIDR. For example: `10.100.0.0/22`. +* *DNS server IP addresses*: the IP of the client VPC's DNS resolver (the second usable IP in the VPC CIDR). For a default VPC with CIDR `172.31.0.0/16`, use `172.31.0.2`. This is what makes PrivateLink hostnames resolve to the endpoint's ENI IPs from connected clients rather than to public DNS. +* *Split-tunnel*: enabled. Only traffic destined for the client VPC CIDR is routed through the VPN; the rest stays on the local internet. +* *VPC ID*: the client VPC where the PrivateLink endpoint lives. +* *Target network association*: associate the endpoint with a subnet in the same VPC as the PrivateLink endpoint. +* *Authorization rule*: allow your client CIDR to reach the client VPC CIDR. + +The client VPN endpoint takes several minutes to reach the *Available* state after the subnet association is created. + +Allow inbound from the client VPN security group on the PrivateLink endpoint's security group, on port `443` (Console / Schema Registry) and on the Kafka API and HTTP Proxy ports (`30000-35999`, covering both the seed and per-broker ports). + +=== Connect using AWS VPN Client + +. Install the https://aws.amazon.com/vpn/client-vpn-download/[AWS VPN Client^] for macOS or Windows. +. From the AWS Console, download the client VPN endpoint configuration file (`.ovpn`). Add your client certificate and private key inside `...` and `...` blocks at the bottom of the file. +. Open AWS VPN Client and choose *File* > *Manage Profiles* > *Add Profile*. Select the `.ovpn` file and give the profile a name. +. Select the profile and click *Connect*. The connection establishes in a few seconds. + +To verify, run the following from the workstation: + +[,bash] +---- +dig +short console-. +---- + +The response should be a private IP from the client VPC's CIDR range. For example: + +[,bash,role=no-copy] +---- +172.31.0.97 +---- + +If the response shows a public address (for example, the cluster VPC's internal LB IPs such as `10.x.x.x`), the VPC's DNS resolver was not pushed to the client. Re-check the *DNS server IP addresses* setting on the client VPN endpoint. + +=== Open Redpanda Console through the Cloud Console left navigation + +With the VPN connected, sign in to the Redpanda Cloud Console at https://cloud.redpanda.com[cloud.redpanda.com^] and select your cluster. + +. The cluster *Overview* page loads as normal; it is served by the Redpanda Cloud control plane and does not depend on the VPN. +. Click any item in the cluster's left navigation (*Topics*, *Brokers*, *Consumer groups*, and so on). These views are served by Redpanda Console at `https://console-.`. With the VPN connected, your browser resolves the hostname to the PrivateLink endpoint's ENI in the client VPC and the views load. +. If the left navigation does not load (the page hangs or returns a network error), confirm the VPN session is connected and that `dig` returns a private IP for the Console hostname. Without an active VPN session, only the cluster *Overview* page is reachable from a workstation outside the client VPC. + +[NOTE] +==== +Redpanda Console does not provide a standalone login form. Do not open `https://console-.` directly in a browser: the SPA loads but cannot complete authentication, because the authentication token is handed off from Redpanda Cloud Console. Always start from https://cloud.redpanda.com[cloud.redpanda.com^]. +==== + == Test the connection You can test the connection to the endpoint service from any VM or container in the client VPC. If configuring a client isn't possible right away, you can do these checks using `rpk` or cURL: diff --git a/modules/networking/partials/private-links-access-rp-services-through-vpc.adoc b/modules/networking/partials/private-links-access-rp-services-through-vpc.adoc index 3a57232c2..21a76c135 100644 --- a/modules/networking/partials/private-links-access-rp-services-through-vpc.adoc +++ b/modules/networking/partials/private-links-access-rp-services-through-vpc.adoc @@ -1,13 +1,14 @@ -You can access Redpanda services such as Schema Registry and HTTP Proxy from the client VPC or virtual network; for example, from a compute instance in the VPC or network. +You can access Redpanda services such as Redpanda Console, Schema Registry, and HTTP Proxy from the client VPC or virtual network; for example, from a compute instance in the VPC or network. The bootstrap server hostname is unique to each cluster. The service attachment exposes a set of bootstrap ports for access to Redpanda services. These ports load balance requests among brokers. Make sure you use the following ports for initiating a connection from a consumer: -|=== -| Redpanda service | Default bootstrap port +|=== +| Redpanda service | Default port -| Kafka API | 30292 -| HTTP Proxy | 30282 -| Schema Registry | 30081 +| Kafka API | 30292 +| HTTP Proxy | 30282 +| Schema Registry | 30081 +| Redpanda Console | 443 |=== === Access Kafka API seed service @@ -53,3 +54,45 @@ Use port `30282` to access the Redpanda HTTP Proxy seed service. ---- curl -vv -u : -H "Content-Type: application/vnd.kafka.json.v2+json" --sslv2 --http2 :30282/topics ---- + +=== Verify the Redpanda Console network path + +When you configure private connectivity through the Cloud API, set `connect_console: true` on the network configuration to enable Console access through the cluster's private endpoint. The Cloud UI sets this for you when you enable private connectivity. + +The Redpanda Console URL is served on port `443` (HTTPS) and follows the form `https://console-.`. The `` is a per-cluster suffix assigned by the Redpanda control plane and is opaque to you; the full URL is shown in the *How to Connect* section of the cluster overview in the Redpanda Cloud Console. + +To verify that the network path to Redpanda Console is open, run the following commands from a host in the client network. First, confirm DNS resolves the hostname to a private IP on the cluster's private endpoint: + +[,bash] +---- +dig +short console-. +---- + +The response is a private IP from your client network's address range, for example: + +[,bash,role=no-copy] +---- +10.0.0.42 +---- + +Then confirm Redpanda Console responds over HTTPS through the endpoint: + +[,bash] +---- +curl -sS -o /dev/null -w "%{http_code}\n" https://console-./ +---- + +Expected output: + +[,bash,role=no-copy] +---- +200 +---- + +A 200 response confirms the network path. The Console UI itself does not expose a standalone login form: sign in to https://cloud.redpanda.com[cloud.redpanda.com^], navigate to the cluster, and use the cluster's left navigation (*Topics*, *Brokers*, *Consumer groups*) to interact with Redpanda Console. + +[NOTE] +==== +* DNS resolution for the Redpanda Console hostname is handled automatically by the cluster's private endpoint. You don't need to create a private hosted zone or override DNS in the client network. +* Ensure your network access rules (for example, AWS security groups, Azure NSGs, or GCP firewall rules) on the private endpoint allow inbound TCP on port `443` from your client workload sources only (for example, the client network's CIDR or specific client access groups). Avoid broad source ranges such as `0.0.0.0/0`. +====