Hi,
We are trying to implement an Edge Cloud platform based on Google Anthos, but we need to adhere to strict corporate policies. One of these policies says that all communication to the Kubernetes clusters needs to be done through a terminal server. This seriously breaks the development lifecycle and is not workable for our developers.
I have been working with this restriction before on plain Kubernetes and I know it is possible to have all communications go through an SSH tunnel to the terminal server. With Google Anthos (and the use of gcloud to retrieve the kubeconfig, I’m a bit lost.
Can someone point me in the right direction to have developers connect to the cluster through an SSH tunnel, so that they can work from their own workstations?
Can you provide documentation for the process you followed when setting up SSH access to your cluster? Accessing a Compute Engine instance through SSH that acts as a proxy to the Kubernetes cluster is detailed in this documentation for setting up as bastion host.
The cluster would not be accessible over the internet, but through the GCE instance that is securely running in the same network.
Hi Ernesto,
We have a Kubernetes cluster created on-premises (with Google Anthos) in Network “A” and our development teams reside in Network “B”. IT Security policies require that developer need to log in to a terminal server (or jumpbox or bastion) that resides in Network “A” first before they are allowed to interact with the Kubernetes cluster. This breaks their workflow, especially on the Development cluster.
I was looking at the solution described here: https://blog.scottlowe.org/2020/06/16/using-kubectl-via-an-ssh-tunnel/ , but we are concerned that gcloud will overwrite the changes made to the kubeconfig. On GCE there is this “tunnel” method as described here: Set up an SSH tunnel for private browsing using Compute Engine | Google Cloud Platform Community , but for Google Anthos this is not the case.
Does the solution you describe also work with a jumpbox on-premises? The article now describes how to do this with a GCE bastion. And I’m wondering if we can also configure TinyProxy on our own server and transparently tunnel through that?
Ok, so I have had a crash course Google Anthos from one of our Engineers and we got part of it working, but it would require end users to add a line to their “hosts” file, which is not the user experience we want to provide (if it is allowed by policy at all).
We log in using gcloud anthos auth login -login-config -cluster . We get redirected to Azure AD where we log in. This results in a kubeconfig being generated containing a certificate and a JWT token (among other things). This certificate only validates against the controlPlaneVIP for the admin cluster and the user cluster (I hope I’m saying this part right :-)). When running the ssh command to open the tunnel we route 127.0.0.1:7443 to the jumpbox and from there to the Kubernetes API Server (controlPlaneVIP). We then get the error that the certificate is only valid for the controlPlaneVIP (and that one other IP address), but not for 127.0.0.1.
I think that what we are looking for is not very exceptional. I’ve seen it done in many organizations (with plain Kubernetes that is). We would be very interested to hear from Google or from the community how we can accomplish this.