В настоящее время...
У меня есть кластер GKE / kubernetes / k8s в GCP. У меня есть бастионный хост (экземпляр виртуальной машины Compute Engine) в GCP. Я разрешил IP-адрес моего хоста-бастиона в кластере GKE Мастер авторизованных сетей раздел. Следовательно, чтобы запустить kubectl команд для моего GKE, мне сначала нужно подключиться к моему хосту-бастиону по SSH, запустив gcloud beta compute ssh команда; затем я запускаю gcloud container clusters get-credentials команда для аутентификации с GKE, затем оттуда я могу запустить kubectl команды как обычно.
Потом...
Я хочу иметь возможность запускать команды kubectl в моем кластере GKE непосредственно из моего локального интерфейса командной строки разработки. Для этого я могу добавить IP-адрес моей локальной машины разработки в качестве разрешенной записи в свой GKE Мастер авторизованных сетей, и это должно быть так. Тогда я могу запустить gcloud container clusters get-credentials сначала, а затем запустить kubectl команды как обычно.
Тем не мение...
Я ищу способ избежать необходимости разрешать IP-адрес моей локальной машины разработки. Каждый раз, когда я беру свой ноутбук в новое место, мне нужно обновить список разрешений для моего нового IP-адреса, прежде чем я смогу запустить gcloud container clusters get-credentials команда перед запуском kubectl команды.
Я думаю...
Есть ли способ назначить номер порта на хосте-бастионе, который можно использовать для безопасного вызова команд kubectl в удаленном кластере GKE? И тогда я могу просто использовать gcloud compute start-iap-tunnel команда (которая, кстати, решает все проблемы с разрешениями с использованием Cloud IAM) из моего локального интерфейса командной строки разработчика, чтобы установить ssh-туннель к этому конкретному номеру порта на хосте-бастионе. Таким образом, для кластера GKE он получает kubectl команды от хоста бастиона (который уже разрешен в его Мастер авторизованных сетей). Но за кулисами я аутентифицируюсь с помощью хоста-бастиона из моего локального интерфейса командной строки разработчика (используя мои учетные данные glcoud auth) и вызываю kubectl команды оттуда безопасно.
Это возможно? Есть идеи от кого-нибудь?
Добавление вашего IP в Master authorized network было бы проще. Вы можете написать сценарий, который получает внешний IP-адрес вашего портативного компьютера и добавляет его в главный список авторизованных сетей GKE, а затем использовать тот же сценарий для удаления IP-адреса после завершения. Но поскольку это не кажется вам вашим предпочтением, позвольте мне дать подробный ответ на вопрос, как этого добиться с помощью хоста для прыжков.
Во-первых, вам понадобится программа перенаправления портов на бастионе хозяина. При этом запросы, попадающие в порт бастиона, будут перенаправлены на главный IP-адрес GKE. Я предполагаю, что здесь вы используете частный кластер - и узлы, и главный сервер api находятся в частной сети.
На бастионном войске -
sudo apt-get update && sudo apt-get install redir -y
redir --laddr=0.0.0.0 --lport=8443 --caddr=172.16.0.32 --cport=443 -l debug
Приведенная выше команда перенаправит запросы на порт бастиона 8443 на главный узел GKE (172.16.0.3) - не стесняйтесь изменять это в зависимости от ваших настроек.
На вашем ноутбуке -
gcloud compute ssh bastion --zone $ZONE --ssh-flag="-L 8443:localhost:8443"
Теперь вы создали ssh-туннель от вашего ноутбука до хоста-бастиона. Вызовы на localhost через порт 8443 будут перенаправлены на сервер API GKE.
Создать конфигурацию куба -
gcloud container clusters get-credentials $CLUSTER_NAME [--zone $ZONE | --region $REGION]
Наконец, обновите раздел сервера в ~/.kube/config следующим образом -
server: https://127.0.0.1:8443
Если вы сейчас запустите команды kubectl, вы все равно столкнетесь с ошибкой сертификата ssl -
$ kubectl version --short
Client Version: v1.15.11-dispatcher
Unable to connect to the server: x509: certificate is valid for ***, not 127.0.0.1
Чтобы убедиться, что установка работает, вы можете пропустить проверку tls с помощью --insecure-skip-tls-verify. ПРИМЕЧАНИЕ. Пропуск проверки TLS НЕ рекомендуется из соображений безопасности.
$ kubectl version --short --insecure-skip-tls-verify
Client Version: v1.15.11-dispatcher
Server Version: v1.15.12-gke.2
Один из способов решения проблемы проверки сертификата - создать на портативном компьютере псевдоним IP-адреса, который соответствует частному адресу сервера API GKE. В дополнение к этому, обновите конфигурацию kube, чтобы она соответствовала этому.