Skip to content

Commit 638d73b

Browse files
david-yuclaude
david-yu
and
claude
authored
docs(networking): document Console access over AWS PrivateLink (#594)
* docs(networking): document Console access over AWS PrivateLink Adds a Console row to the PrivateLink services table and a new "Access Redpanda Console" subsection in the shared partial. Engineering confirmed that DNS for the Console hostname is auto-resolved by the verified private DNS name on the endpoint service, so consumers do not need to create a private hosted zone or override DNS. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(networking): add step-by-step verify for Console over PrivateLink Verified end-to-end against a private BYOC cluster with a PrivateLink endpoint in a consumer VPC: - Cluster DNS publicly returns service-side LB IPs (10.0.x.x). - From inside the consumer VPC, dig returns the endpoint's ENI private IP (e.g. 172.31.0.97) via the verified private DNS name `*.<cluster_domain>` registered on the endpoint service. - curl returns HTTP 200 with title "Redpanda Console" served over HTTPS through the endpoint. Corrects the Console URL form from `console.<cluster_domain>` to `console-<id>.<cluster_domain>` (the random per-cluster id suffix the control plane assigns), and points to the *How to Connect* section as the authoritative source. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(networking): add workstation access via AWS Client VPN Adds a new section to the Cloud UI page describing how to access Redpanda Console for a private BYOC cluster from a workstation outside the client VPC. Verified against a real cluster. Key points captured: - Cluster Console for a private BYOC cluster is not browsable directly; the SPA loads but has no standalone login form. Authentication is handed off from Redpanda Cloud Console. - The cluster Overview page on cloud.redpanda.com is served by the control plane and works without a VPN. - The cluster's left navigation (Topics, Brokers, Consumer groups) is served by Redpanda Console behind PrivateLink, so it only loads when the workstation has a VPN session into the client VPC. - AWS Client VPN settings specific to PrivateLink: client CIDR must not overlap VPC CIDR, DNS server IPs must point at the VPC's resolver (so Console hostnames resolve via the endpoint ENI), split-tunnel enabled. Softens the partial's Console section from "browse to the URL" to a network-path verification, with a forward reference to the workstation flow on the Cloud UI page. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(networking): add workstation → cluster network path diagram ASCII diagram in the workstation access section showing the two-hop flow: Client VPN puts the laptop into the client VPC, then PrivateLink carries the connection to the cluster. Clarifies that Client VPN itself does not use PrivateLink — the VPN is just one of several ways a client can reach the VPC, and PrivateLink is the constant once you're inside. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(networking): address PR review feedback - Drop "only" in the workstation intro; Console is reachable through other private routes too (VPC peering, transit gateway). Per @paulzhang97 review. - Widen the Client VPN inbound port range from 30000-30999 to 30000-35999 to cover both seed and per-broker Kafka API and HTTP Proxy ports. Per @paulzhang97 review. - Tighten partial's port 443 SG guidance to scope inbound to client workload sources (consumer VPC CIDR or specific client security groups) and call out that broad source ranges like 0.0.0.0/0 should be avoided. Per @coderabbitai nitpick. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(networking): address review from @micheleRP Critical #1: Partial is shared across AWS/Azure/GCP — content must be provider-neutral. Replaced AWS-specifics in the Console verify section: "PrivateLink endpoint" → "cluster's private endpoint", example IP 172.31.0.97 → 10.0.0.42, "client VPC" → "client network", and dropped the xref to the AWS-only workstation section. AWS UI page now has a short forward link to the workstation section immediately after the partial include. Critical #2: Cloud API flow's connect_console requirement was silent. Added a sentence stating that the Cloud API requires connect_console: true and that the Cloud UI sets it automatically. Removed the now- obsolete "Confirm with engineering" item from the PR test plan. Critical #3: "API gateway access PRIVATE/PUBLIC" is not a documented term anywhere in the repo. Dropped the bullet rather than reintroduce a verbose explanation of networking_config out of scope for this PR. Critical #4: Workstation intro contradicted the partial's PUBLIC bullet. Resolved by Critical #3 (PUBLIC bullet is gone); the workstation intro already scopes to private clusters. Suggestion #6: Widened AWS Client VPN client CIDR from "/22 or larger" to "/22 (minimum) to /12 (maximum)" per AWS's documented constraint. Suggestion #5: Console URL <id> opaque note clarified. NOTE block in the partial now also frames inbound rules as cloud-neutral ("AWS security groups, Azure NSGs, or GCP firewall rules") so the guidance is accurate when the partial renders on non-AWS pages. Skipped (with rationale in reply): Suggestion #7 (Mermaid — style only) and Suggestion #8 (page split — bigger refactor for a follow-up). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(networking): convert workstation network-path diagram to Mermaid Per @micheleRP suggestion #7, switches the ASCII flow diagram to a Mermaid flowchart using the @sntke/antora-mermaid-extension already configured in local-antora-playbook.yml. Preserves the original flow: five top-to-bottom nodes (Workstation → AWS Client VPN endpoint → Client VPC subnet → PrivateLink VPC endpoint ENI → Redpanda cluster VPC → Console load balancer → Redpanda Console), the same edge labels between them, and the two side annotations ("AWS-managed; not PrivateLink" next to the Client VPN endpoint, "PrivateLink begins here" next to the PrivateLink ENI) as parallelogram note shapes attached with dashed links. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Revert "docs(networking): convert workstation network-path diagram to Mermaid" This reverts commit 7bb3423. * docs(networking): lowercase descriptor "Client" → "client" "Client" should not be capitalized in body text when used as a descriptor (client VPN tunnel, client VPN endpoint, client VPC subnet, etc.). The capitalized form is reserved for proper nouns: - "AWS Client VPN" — AWS service name - "AWS VPN Client" — AWS desktop application name - "Client IPv4 CIDR" — AWS UI field label Seven occurrences updated; the three proper-noun forms are preserved. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1 parent de058da commit 638d73b

2 files changed

Lines changed: 135 additions & 7 deletions

File tree

‎modules/networking/pages/configure-privatelink-in-cloud-ui.adoc‎

Lines changed: 86 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -70,10 +70,95 @@ include::networking:partial$private-links-aws-client-vpc-setup.adoc[]
7070

7171
== Access Redpanda services through VPC endpoint
7272

73-
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.
73+
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.
7474

7575
include::networking:partial$private-links-access-rp-services-through-vpc.adoc[]
7676

77+
If you are connecting from a workstation outside the client VPC, see <<access-redpanda-console-from-a-workstation>>.
78+
79+
[#access-redpanda-console-from-a-workstation]
80+
== Access Redpanda Console from a workstation
81+
82+
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.
83+
84+
Common VPN options:
85+
86+
* AWS Client VPN attached to the client VPC (described below).
87+
* A corporate VPN configured with a DNS forwarder that resolves `<cluster_domain>` against the client VPC's DNS resolver.
88+
* An SSH SOCKS5 proxy through a bastion host in the client VPC.
89+
90+
The following diagram shows the network path from a workstation, through the VPN, into the client VPC, and across PrivateLink to Redpanda Console:
91+
92+
....
93+
Workstation
94+
│ (public internet, OpenVPN tunnel, mutual TLS)
95+
▼
96+
AWS Client VPN endpoint ← AWS-managed; not PrivateLink
97+
│ (workstation is now logically inside the client VPC)
98+
▼
99+
client VPC subnet
100+
│ (VPC routing; DNS resolved via VPC resolver to a private IP)
101+
▼
102+
PrivateLink VPC endpoint ENI ← PrivateLink begins here
103+
│ (AWS PrivateLink service network, not on the public internet)
104+
▼
105+
Redpanda cluster VPC → Console load balancer → Redpanda Console
106+
....
107+
108+
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).
109+
110+
=== Set up AWS Client VPN
111+
112+
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:
113+
114+
* *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).
115+
* *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`.
116+
* *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.
117+
* *Split-tunnel*: enabled. Only traffic destined for the client VPC CIDR is routed through the VPN; the rest stays on the local internet.
118+
* *VPC ID*: the client VPC where the PrivateLink endpoint lives.
119+
* *Target network association*: associate the endpoint with a subnet in the same VPC as the PrivateLink endpoint.
120+
* *Authorization rule*: allow your client CIDR to reach the client VPC CIDR.
121+
122+
The client VPN endpoint takes several minutes to reach the *Available* state after the subnet association is created.
123+
124+
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).
125+
126+
=== Connect using AWS VPN Client
127+
128+
. Install the https://aws.amazon.com/vpn/client-vpn-download/[AWS VPN Client^] for macOS or Windows.
129+
. From the AWS Console, download the client VPN endpoint configuration file (`.ovpn`). Add your client certificate and private key inside `<cert>...</cert>` and `<key>...</key>` blocks at the bottom of the file.
130+
. Open AWS VPN Client and choose *File* > *Manage Profiles* > *Add Profile*. Select the `.ovpn` file and give the profile a name.
131+
. Select the profile and click *Connect*. The connection establishes in a few seconds.
132+
133+
To verify, run the following from the workstation:
134+
135+
[,bash]
136+
----
137+
dig +short console-<id>.<cluster_domain>
138+
----
139+
140+
The response should be a private IP from the client VPC's CIDR range. For example:
141+
142+
[,bash,role=no-copy]
143+
----
144+
172.31.0.97
145+
----
146+
147+
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.
148+
149+
=== Open Redpanda Console through the Cloud Console left navigation
150+
151+
With the VPN connected, sign in to the Redpanda Cloud Console at https://cloud.redpanda.com[cloud.redpanda.com^] and select your cluster.
152+
153+
. The cluster *Overview* page loads as normal; it is served by the Redpanda Cloud control plane and does not depend on the VPN.
154+
. 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-<id>.<cluster_domain>`. With the VPN connected, your browser resolves the hostname to the PrivateLink endpoint's ENI in the client VPC and the views load.
155+
. 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.
156+
157+
[NOTE]
158+
====
159+
Redpanda Console does not provide a standalone login form. Do not open `https://console-<id>.<cluster_domain>` 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^].
160+
====
161+
77162
== Test the connection
78163

79164
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:

‎modules/networking/partials/private-links-access-rp-services-through-vpc.adoc‎

Lines changed: 49 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,14 @@
1-
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.
1+
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.
22

33
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:
44

5-
|===
6-
| Redpanda service | Default bootstrap port
5+
|===
6+
| Redpanda service | Default port
77

8-
| Kafka API | 30292
9-
| HTTP Proxy | 30282
10-
| Schema Registry | 30081
8+
| Kafka API | 30292
9+
| HTTP Proxy | 30282
10+
| Schema Registry | 30081
11+
| Redpanda Console | 443
1112
|===
1213

1314
=== Access Kafka API seed service
@@ -53,3 +54,45 @@ Use port `30282` to access the Redpanda HTTP Proxy seed service.
5354
----
5455
curl -vv -u <user>:<password> -H "Content-Type: application/vnd.kafka.json.v2+json" --sslv2 --http2 <http-proxy-bootstrap-server-hostname>:30282/topics
5556
----
57+
58+
=== Verify the Redpanda Console network path
59+
60+
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.
61+
62+
The Redpanda Console URL is served on port `443` (HTTPS) and follows the form `https://console-<id>.<cluster_domain>`. The `<id>` 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.
63+
64+
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:
65+
66+
[,bash]
67+
----
68+
dig +short console-<id>.<cluster_domain>
69+
----
70+
71+
The response is a private IP from your client network's address range, for example:
72+
73+
[,bash,role=no-copy]
74+
----
75+
10.0.0.42
76+
----
77+
78+
Then confirm Redpanda Console responds over HTTPS through the endpoint:
79+
80+
[,bash]
81+
----
82+
curl -sS -o /dev/null -w "%{http_code}\n" https://console-<id>.<cluster_domain>/
83+
----
84+
85+
Expected output:
86+
87+
[,bash,role=no-copy]
88+
----
89+
200
90+
----
91+
92+
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.
93+
94+
[NOTE]
95+
====
96+
* 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.
97+
* 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`.
98+
====

0 commit comments

Comments
 (0)