From 48c0c1dbad635ddeeea5c9bfca52a10563f43684 Mon Sep 17 00:00:00 2001 From: "Matt Linville (he/him)" Date: Fri, 15 Dec 2023 15:17:00 -0800 Subject: [PATCH] [DOC-426] Amend the note about enabling global access (#18160) * [DOC-426] Amend the note about enabling global access --- .../orchestrate-cockroachdb-with-kubernetes-multi-cluster.md | 4 +--- .../orchestrate-cockroachdb-with-kubernetes-multi-cluster.md | 4 +--- .../orchestrate-cockroachdb-with-kubernetes-multi-cluster.md | 4 +--- 3 files changed, 3 insertions(+), 9 deletions(-) diff --git a/src/current/v22.2/orchestrate-cockroachdb-with-kubernetes-multi-cluster.md b/src/current/v22.2/orchestrate-cockroachdb-with-kubernetes-multi-cluster.md index d429aaee2cd..7a3fd108438 100644 --- a/src/current/v22.2/orchestrate-cockroachdb-with-kubernetes-multi-cluster.md +++ b/src/current/v22.2/orchestrate-cockroachdb-with-kubernetes-multi-cluster.md @@ -63,9 +63,7 @@ To enable the pods to communicate across regions, we peer the VPCs in all 3 regi #### Exposing DNS servers {{site.data.alerts.callout_danger}} -Until December 2019, Google Cloud Platform restricted clients to using a load balancer in the same region. In the approach documented below, the DNS servers from each Kubernetes cluster are hooked together by exposing them via a load balanced IP address that is visible to the public Internet. None of the services in your Kubernetes cluster will be accessible publicly, but their names could leak out to a motivated attacker. - -You can now [enable global access](https://cloud.google.com/load-balancing/docs/internal/setting-up-internal#ilb-global-access) on Google Cloud Platform to allow clients from one region to use an internal load balancer in another. We will update this tutorial accordingly. +Instead of using this approach, you can now [enable global access](https://cloud.google.com/load-balancing/docs/internal/setting-up-internal#ilb-global-access), which exposes the Kubernetes cluster's DNS servers via a load-balanced IP address that is visible to the public internet. With this this approach, noone of the services in your Kubernetes cluster will be accessible publicly, but their names could leak out to a motivated attacker. {{site.data.alerts.end}} diff --git a/src/current/v23.1/orchestrate-cockroachdb-with-kubernetes-multi-cluster.md b/src/current/v23.1/orchestrate-cockroachdb-with-kubernetes-multi-cluster.md index ba4433dc7cd..cbdad452eb1 100644 --- a/src/current/v23.1/orchestrate-cockroachdb-with-kubernetes-multi-cluster.md +++ b/src/current/v23.1/orchestrate-cockroachdb-with-kubernetes-multi-cluster.md @@ -63,9 +63,7 @@ To enable the pods to communicate across regions, we peer the VPCs in all 3 regi #### Exposing DNS servers {{site.data.alerts.callout_danger}} -Until December 2019, Google Cloud Platform restricted clients to using a load balancer in the same region. In the approach documented below, the DNS servers from each Kubernetes cluster are hooked together by exposing them via a load balanced IP address that is visible to the public Internet. None of the services in your Kubernetes cluster will be accessible publicly, but their names could leak out to a motivated attacker. - -You can now [enable global access](https://cloud.google.com/load-balancing/docs/internal/setting-up-internal#ilb-global-access) on Google Cloud Platform to allow clients from one region to use an internal load balancer in another. We will update this tutorial accordingly. +Instead of using this approach, you can now [enable global access](https://cloud.google.com/load-balancing/docs/internal/setting-up-internal#ilb-global-access), which exposes the Kubernetes cluster's DNS servers via a load-balanced IP address that is visible to the public internet. With this this approach, noone of the services in your Kubernetes cluster will be accessible publicly, but their names could leak out to a motivated attacker. {{site.data.alerts.end}} diff --git a/src/current/v23.2/orchestrate-cockroachdb-with-kubernetes-multi-cluster.md b/src/current/v23.2/orchestrate-cockroachdb-with-kubernetes-multi-cluster.md index ba4433dc7cd..cbdad452eb1 100644 --- a/src/current/v23.2/orchestrate-cockroachdb-with-kubernetes-multi-cluster.md +++ b/src/current/v23.2/orchestrate-cockroachdb-with-kubernetes-multi-cluster.md @@ -63,9 +63,7 @@ To enable the pods to communicate across regions, we peer the VPCs in all 3 regi #### Exposing DNS servers {{site.data.alerts.callout_danger}} -Until December 2019, Google Cloud Platform restricted clients to using a load balancer in the same region. In the approach documented below, the DNS servers from each Kubernetes cluster are hooked together by exposing them via a load balanced IP address that is visible to the public Internet. None of the services in your Kubernetes cluster will be accessible publicly, but their names could leak out to a motivated attacker. - -You can now [enable global access](https://cloud.google.com/load-balancing/docs/internal/setting-up-internal#ilb-global-access) on Google Cloud Platform to allow clients from one region to use an internal load balancer in another. We will update this tutorial accordingly. +Instead of using this approach, you can now [enable global access](https://cloud.google.com/load-balancing/docs/internal/setting-up-internal#ilb-global-access), which exposes the Kubernetes cluster's DNS servers via a load-balanced IP address that is visible to the public internet. With this this approach, noone of the services in your Kubernetes cluster will be accessible publicly, but their names could leak out to a motivated attacker. {{site.data.alerts.end}}