<p>I have created a new GCP Kubernetes cluster. The cluster is private with NAT - not have connection to the internet. I also deploy <code>bastion</code> machine which allow my to connect into my private network (vpc) from the internet. This is the <a href="https://cloud.google.com/nat/docs/using-nat" rel="nofollow noreferrer">tutorial I based on</a>. SSH into <code>bastion</code> - working currently.</p>
<p>The kubernetes master is not exposed outside. The result:</p>
<pre><code>$ kubectl get pods
  The connection to the server 172.16.0.2 was refused - did you specify the right host or port?
</code></pre>
<p>So i install kubectl on <code>bastion</code> and run:</p>
<pre><code>$ kubectl proxy --port 1111
  Starting to serve on 127.0.0.1:3128
</code></pre>
<p>now I want to connect my local <code>kubectl</code> to the remote proxy server. I installed secured tunnel to the <code>bastion</code> server and mapped the remote port into the local port. Also tried it with CURL and it's working.</p>
<p>Now I looking for something like</p>
<pre><code>$ kubectl --use-proxy=1111 get pods
</code></pre>
<p>(Make my local kubectl pass tru my remote proxy)</p>
<p>How to do it?</p>

<p><code>kubectl proxy</code> acts exactly as an apiserver, exactly like the target apiserver - but the queries trough it are already authenticated. From your description, 'works with curl', it sounds like you've set it up correctly, you just need to target the client kubectl to it:</p>

<pre><code>kubectl --server=http://localhost:1111
</code></pre>

<p>(Where port 1111 on your local machine is where <code>kubectl proxy</code> is available; in your case trough a tunnel)</p>

<p>If you need exec or attach trough <code>kubectl proxy</code> you'll need to run it with either <code>--disable-filter=true</code> or <code>--reject-paths='^$'</code>. Read the fine print and consequences for those options.</p>

<h2>Safer way</h2>

<p>All in all, this is not how I access clusters trough a bastion. The problem with above approach is if someone gains access to the bastion they immediately have valid Kubernetes credentials (as kubectl proxy needs those to function). It is also not the safest solution if the bastion is shared between multiple operators. One of the main points of a bastion would be that it never has credentials on it. What I fancy doing is accessing the bastion from my workstation with:</p>

<pre><code>ssh -D 1080 bastion
</code></pre>

<p>That makes ssh act as SOCKS proxy. You need <code>GatewayPorts yes</code> in your sshd_config for this to work. Thereafter from the workstation I can use</p>

<pre><code>HTTPS_PROXY=socks5://127.0.0.1:1080 kubectl get pod
</code></pre>
