Web UI используется активно. В плоской иерархии очень много SE примонтированно. Но даже админам волта не доступен лист всех маунтопоинтов, т.к. это не зачем. Каждый имеет минимально необходимый набор прав.
Ох, прошу прощения за долгий ответ. Конкретно в компании очень большой и производительный SOC. Все аудит логи важны.
Возможно можно на уровне файлбита или вектора сбрасывать часть аудит логов. Те же токен истёк не самые полезные почти всегда. Особенно если учесть то что он хэшируется прежде чем попасть в лог.
Закинул к себе на доску попробовать сделать инсталляцию на docker-compose с выбрасыванием части аудит логов. Но не смогу по времени сориентировать, т.к. планов много, а времени не оч.
В посте намеренно нет тезисов "какие мы молодцы", потому что это никому не интересно. Пост про опыт построения сервиса для хранения и использования секретов. О том с какими сложностями столкнулись и как исправляли.
История с 7 избыточными ключами из которых необходимо всего лишь 3, да и то не сразу смогли собрать: Показывает что без постоянных проверок и готовности ввести свою часть ключа мы не получили высокую доступность, т.к. ключи могут быть потеряны, забыты, или ещё какой фактор может сработать.
История про бэкапы: Не было видно по графиками что что-то совсем пошло не так. Час от часу бэкап рос на 4Мб, ну мало ли, команды сохраняют секреты, пользуются сервисом, хорошо ведь. И только когда случился сбой: сервис стал очень сильно тормозить, мы начали копать чтобы понять что пошло не так. Также если у вас инфра в виртуалках, и надо запускать задачи по крону, затрагивается вопрос мониторинга таких задач. В кубе проще, там есть cronJob и видно статус. В виртуалках для запуска бжкапа из CI и по рассписанию, запустили сервис webhook.
+ мониторинг: SLA, SLO, SLI + стандарты по именованию и автоматизация рутины, чтобы не превратить инсталляцию в ад поддержки. У некоторых команд более 15 волтовых групп АД с разными доступами, с разными списками участников, с разными требованиями от ИБ по мониторингу таких групп. Можно было передать управление такими группами на первую линию, но это человеческий фактор и увеличение нагрузки на людей тем что можно автоматизировать.
Я надеюсь что смог раскрыть эти темы, и поделиться опытом, который, возможно, даже окажется полезным другим инженерам при построении их систем.
Каждый инструмент под свою задачу. Мы решали наши проблемы под которые волт больше подходит. Итоговая инфраструктура появилась не сразу. Первоначально она выглядела так: * Балансер для возможности проводить работы на одной и более нод волта * Волт в кол-ве 3 инстанса для отказоустойчивости и доступности 24х7 * Консул как хранилище для хранения БД волта. Но он уже был запущен на всю компанию, т.к. использовался в Service Discovery.
И по чуть-чуть для улучшения доступности сервиса, для закрытия выясненных проблем инфраструктура менялась, порой усложнялась, порой упрощалась. На сколько знаю, сейчас переводят волт на Raft хранилище, что даёт свои плюсы и минусы.
Доброго дня, Никак не прокомментирую. Эта статья расшифровка моего выступления в 2019-м году https://www.youtube.com/watch?v=pP8909tFllM с поправкой на изменения за последние 3 года. Я, также, не могу выложить статью в свой личный блог, т.к. и доклад и статья это труд многих людей работающих, или работавших, в Тинькофф: * Команды которые создавали потребности в инструменте и автоматизации вокруг него * Коллеги, которые ревьюили и помогали менять текст выступления * Коллеги, которые ревьюили и правили текст этой статьи
Готов ответить на вопросы по волту, хранению секретов, по автоматизации вокруг инсталляции.
Про права: Ansible получает минимально необходимые для его работы права: * Управление политиками (единственная уз с такими правами на весь кластер) * Управление Auth Backend и учётками внутри * Управление Secrets Engine * Управление некоторыми системными вызовами, например управление аудит устройствами
Про имена объектов: У каждого проекта свой префикс, добавляемый каждому объекту, что исключает пересечение по именам. Например: * project1__kv <= SE * project1__kv-rw <= Policy * project1__kv-ro <= Policy * project2__kv <= SE * project2__transit <= SE
Ansible может запросить список объектов, например примонтированных SE, далее по префиксу понять какие объекты относятся к проекту конфиги которого сейчас применяются. Далее идёт сортировка в 3 списка: * Удалить, если более не описано в конфигурации * Обновить, если описано и существует * Создать, если описано и не существует
Про доступ из одного проекта в другой: Глобально запрещено обращаться к объектам чужого проекта. Коллеги написали валидатор на Open Policy Agent, который проверяет пути в политиках. Если встречается обращение за рамки своего проекта, кроме некоторых путей, пайплайн не пройдёт.
Web UI используется активно. В плоской иерархии очень много SE примонтированно. Но даже админам волта не доступен лист всех маунтопоинтов, т.к. это не зачем. Каждый имеет минимально необходимый набор прав.
То что примонтировано 100500 SE никому не мешает.
Жёсткое разграничение по проектам, ревью доступов.
Ох, прошу прощения за долгий ответ.
Конкретно в компании очень большой и производительный SOC. Все аудит логи важны.
Возможно можно на уровне файлбита или вектора сбрасывать часть аудит логов. Те же токен истёк не самые полезные почти всегда. Особенно если учесть то что он хэшируется прежде чем попасть в лог.
Закинул к себе на доску попробовать сделать инсталляцию на docker-compose с выбрасыванием части аудит логов. Но не смогу по времени сориентировать, т.к. планов много, а времени не оч.
В посте намеренно нет тезисов "какие мы молодцы", потому что это никому не интересно. Пост про опыт построения сервиса для хранения и использования секретов. О том с какими сложностями столкнулись и как исправляли.
История с 7 избыточными ключами из которых необходимо всего лишь 3, да и то не сразу смогли собрать:
Показывает что без постоянных проверок и готовности ввести свою часть ключа мы не получили высокую доступность, т.к. ключи могут быть потеряны, забыты, или ещё какой фактор может сработать.
История про бэкапы:
Не было видно по графиками что что-то совсем пошло не так. Час от часу бэкап рос на 4Мб, ну мало ли, команды сохраняют секреты, пользуются сервисом, хорошо ведь. И только когда случился сбой: сервис стал очень сильно тормозить, мы начали копать чтобы понять что пошло не так.
Также если у вас инфра в виртуалках, и надо запускать задачи по крону, затрагивается вопрос мониторинга таких задач. В кубе проще, там есть cronJob и видно статус. В виртуалках для запуска бжкапа из CI и по рассписанию, запустили сервис webhook.
+ мониторинг: SLA, SLO, SLI
+ стандарты по именованию и автоматизация рутины, чтобы не превратить инсталляцию в ад поддержки. У некоторых команд более 15 волтовых групп АД с разными доступами, с разными списками участников, с разными требованиями от ИБ по мониторингу таких групп. Можно было передать управление такими группами на первую линию, но это человеческий фактор и увеличение нагрузки на людей тем что можно автоматизировать.
Я надеюсь что смог раскрыть эти темы, и поделиться опытом, который, возможно, даже окажется полезным другим инженерам при построении их систем.
Каждый инструмент под свою задачу. Мы решали наши проблемы под которые волт больше подходит. Итоговая инфраструктура появилась не сразу. Первоначально она выглядела так:
* Балансер для возможности проводить работы на одной и более нод волта
* Волт в кол-ве 3 инстанса для отказоустойчивости и доступности 24х7
* Консул как хранилище для хранения БД волта. Но он уже был запущен на всю компанию, т.к. использовался в Service Discovery.
И по чуть-чуть для улучшения доступности сервиса, для закрытия выясненных проблем инфраструктура менялась, порой усложнялась, порой упрощалась. На сколько знаю, сейчас переводят волт на Raft хранилище, что даёт свои плюсы и минусы.
Доброго дня,
Никак не прокомментирую. Эта статья расшифровка моего выступления в 2019-м году https://www.youtube.com/watch?v=pP8909tFllM с поправкой на изменения за последние 3 года.
Я, также, не могу выложить статью в свой личный блог, т.к. и доклад и статья это труд многих людей работающих, или работавших, в Тинькофф:
* Команды которые создавали потребности в инструменте и автоматизации вокруг него
* Коллеги, которые ревьюили и помогали менять текст выступления
* Коллеги, которые ревьюили и правили текст этой статьи
Готов ответить на вопросы по волту, хранению секретов, по автоматизации вокруг инсталляции.
Доброго дня,
Про права:
Ansible получает минимально необходимые для его работы права:
* Управление политиками (единственная уз с такими правами на весь кластер)
* Управление Auth Backend и учётками внутри
* Управление Secrets Engine
* Управление некоторыми системными вызовами, например управление аудит устройствами
Про имена объектов:
У каждого проекта свой префикс, добавляемый каждому объекту, что исключает пересечение по именам. Например:
* project1__kv <= SE
* project1__kv-rw <= Policy
* project1__kv-ro <= Policy
* project2__kv <= SE
* project2__transit <= SE
Ansible может запросить список объектов, например примонтированных SE, далее по префиксу понять какие объекты относятся к проекту конфиги которого сейчас применяются. Далее идёт сортировка в 3 списка:
* Удалить, если более не описано в конфигурации
* Обновить, если описано и существует
* Создать, если описано и не существует
Про доступ из одного проекта в другой:
Глобально запрещено обращаться к объектам чужого проекта. Коллеги написали валидатор на Open Policy Agent, который проверяет пути в политиках. Если встречается обращение за рамки своего проекта, кроме некоторых путей, пайплайн не пройдёт.