Комментарии 9
Vault отлично умеет подписывать ssh-ключи ssh-сертификатами, что делает его вполне приемлимым для временной авторизации кого-то для доступа на сервер.
Что у sops есть для этого?
SOPS это локальная утилита вроде Ansible Vault. Она для другого.
А SSH, как по мне, давно удобнее настроить на вытаскивание ключей из LDAP и рулить доступами там.
Главная проблема LDAP'а в том, что это realtime сервис. Лёг ldap, инфраструктура не доступна. Если вы можете избежать realtime зависимости от чего-то, лучше её избегать.
Суточный ssh-сертификат - это, как мне кажется, очень разумная конструкция. Даже если авторизационный сервер лёг, мы всё ещё можем ходить на сервера, business as usual, так сказать. При этом утечка ssh-ключа во-первых сама по себе ни чем не грозит (нужен сертификат) а во-вторых, даже в случае утечки вместе с сертификатом, оказывается ограничена по времени.
LDAP прекрасно делается отказоустойчивым.
У нас инфраструктура на тысячи хостов работает через 4 LDAP сервера, настроенные в SSSD везде. Чтобы все 4 упали - крайне маловероятно. Но даже в этом случае есть fallback-пользователь и рутовый пароль.
За многие годы проблем с этим сетапом не было. А чтобы всё было локально - это нужно раскатывать конфигурации на всё постоянно, следить за всем этим...
Скажите, а кто вам обеспечивает качество работы сети? У вас ни разу межконтинентальная сеть не падала? Вот буквально вчера "крысы на побережье погрызли что-то". А если вы в каждой точке присутствия будете разводить по 4 LDAP-сервера, то это несколько сотен серверов только во имя надёжности LDAP.
Альтернатива - просто не закладываться на realtime availability. Перед тем, как делать что-то невероятно надёжным лучше задуматься, а нужно ли делать что-то, от чего требуется невероятная надёжность. Иногда батарейка прекрасно заменяет собой атомный реактор, и можно существенно сэкономить на активных и пассивных системах безопасности.
Краткосрочные сертификаты очень хорошо эту проблему решают.
А вот "fallback-пользователь и рутовый пароль" - это give up. Либо персонал его знает (и тогда, нафига всё городить?), либо не знает, и у вас availability страдает.
Сделать так, чтобы ssh-сервер доверял CA - тривиально. Сделать CA для выпуска сертификатов SSH - уже нет (тот же vault умеет, но неудобно, нужно допиливать), но, повторю, realtime-требования к серверам авторизации - это большое жирное "нет", основывающееся на (лично моём опыте) работы в компаниях с распределённым присутствием.
Альтернатива — просто не закладываться на realtime availability
А можете подробней, как вы решаете эту задачу? Озаботили задачей авторизации на удаленных площадках, в условиях если канал связи лег, и пока что кроме сервера авторизации на каждой площадке, ничего в голову не приходит:(
В двух словах: сервера доверяют ssh-CA, пользователи для логина на сервер должны получить с CA короткоживущий сертификат (~ сутки), которым можно потом пользоваться без участия CA.
CA авторизует пользователей по-старинке (ssh-ключи), выдаёт сертификат с правильными ограничениями и коротким сроком жизни.
Если CA "ложится", то все, у кого есть выпущенный сертификат, могут продолжать работать. Сервер доверяет нескольким CA, так что резервирование не требует кластеризации.
Управление пользователями - это почти как управление пользователями на паре серверов. Ансибл и т.д., но главное достоинство - это одно место, а не тысячи серверов по всему миру.
Познакомился с SOPS благодаря Helmfile и helm-secrets. Было легко настроить и очень удобно использовать. Плюс очень быстро вникаешь в это всё. Поэтому согласен с автором.
Почитал их гитхаб по диагонали и не понял как без AWS KMS рулить шифрованием и доступами в большой команде.
Похоже нужно ставить HashiCorp Vault, рулить в нём и шифровать в SOPS используя Vault как KMS. Какое то шило на мыло...
HashiCorp Vault перехвален, а Mozilla SOPS вместе с KMS и Git неоправданно недооценены