Подключение GCP Kubernetes в частный vpc и NAT

Question

Я создал новый кластер GCP Kubernetes.Кластер является частным с NAT - не имеет подключения к Интернету.Я также развернул bastion машину, которая позволяет мне подключаться к моей частной сети (vpc) из Интернета.Это учебник, основанный на .SSH в bastion - работает в настоящее время.

Хозяин kubernetes не выставлен снаружи.Результат:

$ kubectl get pods
  The connection to the server 172.16.0.2 was refused - did you specify the right host or port?

Поэтому я устанавливаю kubectl на bastion и запускаю:

$ kubectl proxy --port 1111
  Starting to serve on 127.0.0.1:3128

Теперь я хочу подключить свой локальный kubectl к удаленному прокси-серверу.Я установил защищенный туннель на сервер bastion и подключил удаленный порт к локальному порту.Также попробовал это с CURL, и он работает.

Теперь я ищу что-то вроде

$ kubectl --use-proxy=1111 get pods

(Сделать мой локальный kubectl передать через мой удаленный прокси)

Как сделатьэто?

Answer 1

kubectl proxy действует точно как apiserver, точно так же, как целевой apiserver - но запросы через него уже аутентифицированы.Из вашего описания, «работает с curl», звучит так, как будто вы настроили его правильно, вам просто нужно настроить на нем клиентский kubectl:

kubectl --server=http://localhost:1111

(где находится порт 1111 на вашем локальном компьютерегде kubectl proxy доступно; в вашем случае через туннель)

Если вам нужен exec или присоедините желоб kubectl proxy, вам нужно запустить его либо с --disable-filter=true, либо с --reject-paths='^$'.Прочитайте мелкий шрифт и последствия для этих вариантов.

Безопасный путь

В общем, это не то, как я получаю доступ к кластерам через бастион.Проблема с вышеуказанным подходом заключается в том, что если кто-то получает доступ к бастиону, он сразу же имеет действительные учетные данные Kubernetes (так как для работы прокси-сервера kubectl они необходимы).Это также не самое безопасное решение, если бастион распределяется между несколькими операторами.Одним из главных пунктов бастиона было бы то, что на нем никогда не было полномочий.Мне кажется, что я получаю доступ к бастиону с моей рабочей станции с помощью:

ssh -D 1080 bastion

Это делает ssh выступающим в качестве SOCKS-прокси.Вам нужно GatewayPorts yes в вашем sshd_config, чтобы это работало.После этого с рабочей станции я могу использовать

HTTPS_PROXY=socks5://127.0.0.1:1080 kubectl get pod