Комментарии 12
Ничего не понял. Вы Ансибл изобретаете или testinfra?
Ansible для других целей, для развертывания готовой инфраструктуры на сервере. А тут, про создание и интеграцию новых продуктов, я так понял)
Про обратный поток информации: метрики, состояния баз, сервисов итд
например, просто скриншотики
А некоторые места просто непонятны сами по себе, и требуют пояснений, например вот:
Минусы таких систем (с Remote Desktop Access) в том, что они дают все или ничего — потенциально доступ к PROD позволяет все там порушить, хотя, как правило, для анализа проблемы достаточен read-only доступ.
Вот я как раз работаю через PAM. Я хожу на виртуалку, с которой есть доступ к пром серверам, например по ssh. Условно «полный» доступ у меня только к виртуалке, не более (там я могу создавать файлы, например). Доступ к прому — под личной учеткой, и права у нее где-то посредине между read-only и полными, и я не вижу, что бы такое мешало их ограничивать в принипе (кроме лени)? И все действия логируются. А в принципе, есть инструменты способные и запретить что-то (на уровне unix shell скажем).
Где это самое «все или ничего», откуда оно берется — из текста не ясно.
И кстати да, там где паранойя включена по полной, у нас есть доступ только к синонимам в базе данных, которые указывают на view в другой схеме, которые выбирают из таблиц в еще одной схеме только то, что положено видеть нашему приложению. То есть, даже имея доступ, я не смогу выбрать например данные банковских карт. Во view их нет, а создать еще view мне не дадут, да и grant select на таблицу у меня нет тоже. И как ваше решение тут поможет — не улавливается.
по поводу view. Конечно, это рабочее решение. Но у кому принадлежит код view? Если этот дополнительный код поддерживают разработчики продукта, то это хорошо, но это вряд ли, да и невозможно для 3rd party products. А если это DBA допилил, то это а) может развалится с новой версией продукта b) хоть и безопасное, но изменение PROD. Предлагаемый продукт же не только agent-less, но и zero-touch, никаких изменений PROD не нужно
По поводу "откуда оно берется" - если (упрощая) девелоперу нужно дать читать только из таблицы LowLevelLog where DT>=getdate()-1, то именно эта кверь и имлементируется как одна из нод дерева, того, что юзер может делать. Ничего другого он сделать не сможет - просто некуда будет кликнуть.
Да, само собой. Такие вещи требуют изменений в схеме, и для купленных продуктов зачастую невозможны.
>именно эта кверь и имлементируется
Я правильно понял, что вы все возможные действия пользователя в проме пытаетесь заложить в систему как плагины?
Ну, и? Метрики и логи? А чем вам не угодили условно, Nagios (просто первое что пришло в голову), или Prometeus, ну или там Elastic?
Системы мониторинга не дают возможности смотреть на данные - лог таблицы, или вот такое: https://www.actionatdistance.com/filebrowse
Вот это у нас пользуется бешеной популярностью
Тут основная идея в простоте. Попытаюсь объяснить идею. Есть дерево, каждый листовой узел которого может быть 4-х типов - текст, html, chart, downloaded file При раскрытии узлов дерева или при выборе листового узла вызываются Power Shell скрипты, возвращающие либо список нижележащих узлов, либо информацию для листового узла в зависимости от его типа. Все, и больше ничего нет. Доступа к самим скриптам у пользователей нет, они видит только результат его работы. Скрипты выполняются на сервере (node.js), вебморда на vue показывает результат. Скрипты для примера возвращают:
списки серверов
результаты всякого perfmon
некие downloaded логи
тексты объектов бд
и т.д. и т.п. Естественно есть некоторые соглашения по формату, как писать скрипты, они достаточно простые.
DevOps «наоборот», приглашение в проект Bell — action at a distance