Комментарии 20
классную - нужную и безопасную вещь запилили, я похожее раскидывание публичных ключей самоделными скриптами раз в месяц встречаю, отрытое решение?
Телепорт умеет проксировать внутрь себя через 443 а так же его агенты работают по 443 порту, не нужен наружу ssh, ещё полезная фича это публиковать любой web-app, планируется ли подобный функционал? Есть ли возможность кластеризации для возможности обслуживания одной ноды?
Так же у телепорта есть OSe которое собирается из исходников, и без ограничений коммерческой "бесплатной" лицензии, хотелось бы понять чем ваш продукт в этом плане будет лучше?
Что-то отдалённо напоминающее роадмап есть у нас тут https://tuna.am/docs/whats-next/
Телепорт умеет проксировать внутрь себя через 443 а так же его агенты работают по 443 порту, не нужен наружу ssh, ещё полезная фича это публиковать любой web-app, планируется ли подобный функционал? Есть ли возможность кластеризации для возможности обслуживания одной ноды?
Как видно из релиза, это первый шаг в сторону аналога телепорта и пока это только SSH доступ на хосты с аудитом, сертификатами и так далее. Т.е. сделан упор именно на zero trust ,а не сетевую связность и тому подобное. В бальшейшем да планируется и базы данных и web-app и kubernetes. Т.е. пока мы берём на себя только менеджмет ключей и сертификатов, а как клиент придёт к ноде, уже не наша забота, главное безопасно и наблюдаемо. Но у нас есть ещё туннели и в принципе можно анонсить доступ к tuna-bastion через tuna туннель, если у вас серые сети.
Так же у телепорта есть OSe которое собирается из исходников, и без ограничений коммерческой "бесплатной" лицензии, хотелось бы понять чем ваш продукт в этом плане будет лучше?
Телепорт меняет свою лицензию по 5 раз в месяц, условно. И то, что вчера было опенсорс, завтра могут закрыть. При этом цена становится всё заоблачнее. Мы же изначально коммерческий продукт, но с демократичным подходом к цене. Мы предоставляем сервис, который может себе позволить ну любая компания и внедрить у себя мандатный доступ в 2 клика, т.е. доступная безопасность.
Я может чего-то не догоняю, но разве не безопаснее, когда нет третьей стороны?
Вот есть на фирме условный "сервер_х" к которому должны подключаться сотрудники из дома. Ты им прямо в офисе даешь на листочке логин и пароль, они идут домой, со своего компа заходят на https сайт "сервера_х", вводят логин/пароль/смс, скачивают его публичный ключ и отправляют ему свой публичный. Все. Центр сертификации SSL выступает гарантом, что нет MITM.
А уж дальше задача амина "сервера_х" в настройке ролей. Самое простое - rootless контейнер sshd на каждого сотрудника, с ограниченным набором доступных внутренних сервисов через пробросы портов и монтирований папок на нужную внутрянку. Можно базово через sshfs подключать папки для редактирования, можно через git коммитить и т.д. При увольнении сотрудника, просто удаляется контейнер и все.
Проблема классических ssh ключей в том, что они являются аналогом вечного пароля, который ни когда не меняется. Один и тот же ключ можно использовать для разных систем. Нет ни какой возможности отслеживать утечки таких ключей и централизованно отзывать в случае компроментации.
Всё верно, по этому у нас клиенты получают сертификат только на 12 часов, и все сессии мы пишем. И если вы хотите исключить подключение уволенных сотрудников или вообще всех в мараторий, делается это в 2 клика, а не запуском плейбука на 100 хостов с удалением или добавлением ключей.
#1) Генерируем ключ только для работы
ssh-keygen -t rsa -f /home/user/.ssh/id_rsa_my_work
#2) Отправляем публичный ключ на работу админу почтой/голубями/ssh-copy-id и т.д.
#3) Подключаемся используя только рабочий ключ
ssh -F /dev/null -o IdentitiesOnly=yes -i /home/user/.ssh/id_rsa_my_work work.comПри компрометации сообщаешь админу и он удаляет из "authorized_keys" твой публичный ключ id_rsa_my_work.pub. Неужели сложно? Я вот на каждый сервис по отдельному ключу имею, т.к. чисто подкоркой страшно, один и тот-же пихать везде, словно один пароль на все сервисы.
Ну в рамках командной работы нужна ещё наблюдаемость. Как вы узнаете, что другой сотрудник делает также? А если не делает и оставил незалоченный комп в кафе и его .ssh каталог скопировал кто-то, или он случайно запушил его в публичную репу?
А как вы поймётие, что после увольнения недобросовестный сотрудник не оставил левые ключи о которых вы не знаете у левых пользователей на сервере, о которых вы незнаете в authorized_keys ?
А если база утекла как вы узнаете кто, когда заходил и какие команды выполнял? Как тут поможет то, что у вас на каждый сервер отдельный ключ ?))
Насколько я разобрался, ваше api дает интерфейс для работы с pki, а выдаваемые им сертификаты x509 используются для подключения к серверам. При этом сертификаты быстро протухают и требуют перевыпуска. А почему не использовать персонализированную revoke базу, чтобы точечно отзывать сертификаты ? Я так по 100 раз за день дергаю компы , и обновлять бы раздражало их.
Аппаратные ssh ключи вроде решают вопрос с безопасностью. Приватный ключ не экспортируется, без pin кода им не воспользоваться . Отозвать его vi…dd… по тегу не сложно.
Вы в живой природе в небольшой компании видели такое хоть раз? Я в банке то не видел.
А кто тогда целевая аудитория? Мелким компаниям все равно на безопасность, да и многим средним, у крупных свои админы и безопасники.
Я пользуюсь на добровольных началах ). Однако, я почему это написал-то, тот же yubikey стоит 5-10к, покупаешь его один раз и все. А использовать сторонний продукт - это расходы по «абонентской плате», плюс ко всему, сегодня абонентская плата 100р, а через год 1к.
А в чем отличие от step ca?
step ca - https://smallstep.com/ , как и телепорт и подобные, более зрелые решения, мы только в начале пути, но суть таже да.
Tuna bastion — безопасный SSH доступ, альтернатива Teleport и HashiCorp Boundary