bbelky 27 фев 2019 в 10:28

Kubespray-as-a-Service — добавляем Kubernetes к любому облаку

2 мин

DevOps*Облачные сервисы*Микросервисы*Kubernetes*

+20

Комментарии 38

maxim_ge 27 фев 2019 в 10:55

Это круто. Не совсем уловил про ключ.

который нужно положить на серверы, которые вы будете использовать для вашего кластера

Если это ключ для SSH Key-Based Authentication, то его установка требует определенных манипуляций. Или подразумевается, что если решил поставить kubernetes, то про ключи уже должен знать досконально?

bbelky 27 фев 2019 в 11:02

Спасибо за комментарий, да, возможно я переборщил с предположениями;) Добавлю ссылочку на гайд.

maxim_ge 27 фев 2019 в 11:13

И еще в связи с этим вопрос, вроде бы имя пользователя нигде не вводится — как так? Разве можно обойтись без этого?

bbelky 27 фев 2019 в 11:26

Мы везде по-умолчанию используем пользователя root. Собственно, пользователя может потребоваться вводить только, если вы добавляете ключи на сервер вручную.

pxemul 27 фев 2019 в 11:36

Да, это ключик для того, чтобы ansible мог зайти на ваши сервера и сделать что ему нужно. В… обычной (когда из терминала запускаете) ситуации он может, конечно, пароль спросить, но в форме сервиса спрашивать пароль не у кого, сами понимаете :) Так что пока ключики.

Это, конечно, хлопотно гонять пользователя раскладывать ключи по своим серверам, у нас есть три продолжения этой темы:
1. будет дока, которая расскажет как разложить ключи по серверам (surprise, surprise) запустив ansible из терминала и введя проль(-и)
2. мы предложим вариант загрузки на wigin готового private ключа, если вдруг у пользователя уже готова key-based auth на его машины
3. будет возможность создавать vm-ы для разворачивания в публичных облаках, при таком раскладе все ключи будут разложены автомагически

dmitriylyalyuev 27 фев 2019 в 11:59

Вы серьезно? root? Вот прямо так сразу?
Мой внутренний параноик застрелился сразу после прочтения!

pxemul 27 фев 2019 в 12:03

Ну вы как бы хотите, чтобы вам на машину пакетов поставили (и сеть сконфигурировали). Даже если и не root, то пользователь из sudo списка нужен будет в любом случае.

dmitriylyalyuev 27 фев 2019 в 12:05

Именно поэтому я и не хочу. Я и сам с kubeadm подниму все, что мне надо. И хосты будут внутри периметра безопасности. Туда внешний сервис по SSH не попадет при всем желании.

А тем кому нужен такой сервис — буду читать о них в сводках об утечках инфы пользователей.

bbelky 27 фев 2019 в 12:19

Этот сервис для тех, кто деплоит куб на публичные облака. Если серверы и их данные должны быть в изолированном периметре, то это, понятное дело, другой вопрос. Что же касается публичного облака, Вы же не думаете, что провайдеры не имеют доступ к Вашим данным?)

dmitriylyalyuev 27 фев 2019 в 12:22

Имеют. Но доверять данные Амазону или DO (публичное облако), и доверять данные стартапу, у которого даже Privacy Policy не описано… Не находите, что это разные вещи?

pxemul 27 фев 2019 в 12:36

Данные? Какие данные? Сделали две пустых VM-ы, положили ключи, развернули, убрали ключи.

dmitriylyalyuev 27 фев 2019 в 12:37

И при первой нормальной нагрузке — легли. Отличное решение!

pxemul 27 фев 2019 в 12:39

При чём тут нагрузка? Вы даёте сервису на ремя доступ к машинам, который можете в любой момент прекратить. Почему это называется «доверять данные непонятному стартапу»?

dmitriylyalyuev 27 фев 2019 в 12:43

Именно потому, что вход по SSH нужно давать только тому, кому вы на 300% доверяете. Есть гарантии того, что при установке k8s не будет добавлена закладка для слива данных? Я не хочу сказать, что это сделают создатели стартапа. Я хочу сказать, что в случае их взлома может быть добавлен код, который будет укладывать закладки на все сервера, где они будут разворачивать k8s.

Это огроменный риск. И я не готов рисковать данными моих пользователей вот таким глупым образом.

pxemul 27 фев 2019 в 13:06

Гарантий полной безопасности, конечно, нет, соизмерять получаемые риски с удобствами от использования технологий, безусловно нужно. И мы все, конечно же, слышали про километры угнанных паролей от фейсбуков и гуглов и (наверное) стараемся самые сокровенные свои данные даже им не доверять. Степень сокровенности у каждого, понятно, своя. Спасибо, что напомнили нам об этом.

dmitriylyalyuev 27 фев 2019 в 13:10

Сама идея, для развертывания тестовых штук, на поиграться, на потыкать — огонь. К примеру, сделать конфигуратор — хочу Istio, RBAC, Ingress Nginx (Traefik, HAProxy, etc) и т.п. В общем для того, чтоб не вникать в набор технологий, но пощупать их.

Потом можно уже вникать и разбираться как это все устроено и работает, чтоб перенести на стейдж и прод.

В любом случае — найдутся те, кто будет пользоваться сервисом. Тема хайповая. :)

pxemul 27 фев 2019 в 13:14

Именно! А ещё ведь можно написать bbelky и спросить можно ли развернуть эту штуку «внутри своего периметра безопасности» ;)

dmitriylyalyuev 27 фев 2019 в 13:25

Ненене. Разбираться и только… Иначе когда эта штука с грохотом нагребнется (не «если», и именно «когда»), то лечить придется руками и тут уже надо знать что, как, зачем и почему. ;)

bbelky 27 фев 2019 в 13:41

Wigin будет Open Source. Просто мы сначала запустили его как сервис, чтобы проверить жизнеспособность самой идеи. Сейчас доделаем деплоилку и выложим на github.

При таком раскладе будет интересно?

dmitriylyalyuev 27 фев 2019 в 13:43

Вот такой подход более интересен. Код можно проверить, развернуть в своем стеке и деплоить окружения.

Спасибо.

bbelky 5 мар 2019 в 19:14

Заопенсорсили и выложили на gitlab:
Backend: gitlab.com/wiginio/wigin-core
Dashboard: gitlab.com/wiginio/wigin-ui
Велкам!

dmitriylyalyuev 5 мар 2019 в 21:23

Спасибо. Прямо молодцы. :) Удачи в начинании.

bbelky 27 фев 2019 в 12:39

Согласен. Но DO тоже был стартапом, да. Privacy Policy добавим.

dmitriylyalyuev 27 фев 2019 в 12:46

Дело не только в Privacy Policy. Там еще куча всего должно быть.
Пример, что будет, если ваша инфраструктура будет скомпрометирована? Будет внедрена закладка в процесс деплоя k8s и эта закладка будет распространяться по серверам клиентов? Ботнет — это самое простое, что я вижу тут. Большой ботнет.

Ну и никто не запрещает потом ей открывать бэкдор, сливать базы данных и все, что угодно. Тем более, что она будет установлена с правами root!

Это абсолютнейший контроль над системой.

pxemul 27 фев 2019 в 13:06

Помнится, ещё в прошлом веке я видел элктронную записную книжку от Casio, в мануале на которую было написано что-то вроде: «посколько у нас современный высокотехнологичный продукт, то мы вам настоятельно рекомендуем самые ценные ваши записи держать не в нём, а на бумаге».

kvaps 27 фев 2019 в 12:28

Хотя бы sudo сделайте, kubespray умеет же в become.

pxemul 27 фев 2019 в 12:37

+1

хотя тут телодвижений больше для клиента. Не только ключи разложить, но ещё и пользователя в sudoers добавить.

kvaps 27 фев 2019 в 13:03

Что может быть проще?

useradd -m wigin -s /bin/bash
mkdir -p /home/wigin/.ssh
echo $SSH_KEY > /home/wigin/.ssh/authorized_keys
echo 'wigin ALL=(ALL) NOPASSWD:ALL' > /etc/sudoers.d/wigin

pxemul 27 фев 2019 в 13:08

Да, да, да, но это надо сделать на каждой машине, которую вы регистритуете в wigin. Надо будет сделать что-то в стиле вот этого.

pxemul 27 фев 2019 в 12:22

Да, конечно, вы всё абсолютно правильно говорите. Кто может сам… ну, скажем, переклеить обои и побелить потолок, тот ~~за железной дверью~~ внутри периметра безопасности делает это сам. Кто не может (или не хочет), пользуется услугами специалистов. С определённым риском попасть в какие-нибудь интересные сводки.

kharkevich 27 фев 2019 в 14:22

Поздравляю, вы изобрели Ansible Tower или Polemarch в SaaS виде :)

bbelky 27 фев 2019 в 14:34

Спасибо за поздравления) Так и есть — смысл wigin именно в том, что он сервис, который не нужно деплоить и поддерживать самостоятельно. При этом при желании, можно развернуть его у себя, он же опенсорсный. Такая концепция интересна? Собственно мы его сюда и выложили, чтобы спросить комьюнити, интересен ли такой сервис.

kharkevich 27 фев 2019 в 18:49

Как селф-хостед решение — возможно. Но лично для меня не вариант, ибо проигрывает тому же Ansible Tower по всем фронтам.
Как часть некого публичного клауда — вполне себе, но как выше написали Privacy Policy и всё такое (хотя это больше к клауду который данный сервис предостовлят).
Как отдельный сервис в чистом виде — однозначно нет, т.к. эта штука получает полный и непрозрачный контроль над моей инфраструктурой (или её частью)

dleonik 27 фев 2019 в 18:50

Опенсорсный самое оно ибо очень не хочется давать ssh =)

bbelky 27 фев 2019 в 22:02

Хорошо, безусловно, будет опенсорс вариант доступный on-premises. Все-таки в чем привлекательность опенсорс в данном конкретном случае, если сам вигин изначально предполагается как сервис, который из облака? По такой модели работает, например, bitnami, который тоже имеет доступ ко всему в вашем облаке.