во многих сложных системах, безусловно, есть не только внутренние хосты, видимые со специально оговоренных IP-адресов, но и внешние, либо динамическим списком IP-адресов, вот в таком случае, велик шанс, что злоумышленнику, получившему валидную пару логин-пароль удастя получить контроль над БД на уровне сервиса, предроставляющего доступ извне, путем подмены IP-адреса, либо MTM, либо несколькими другими способами, (0-Day, и т.д.)
Конечно я использую изляцию Docker-a, например, eсли использовать, к примеру Google Cloud Computing + Docker, то очень быстно выяснится, что
1) вся ВМ, все диски, все свапы — шифруются,
2) при использовании Docker-a внутри Google Cloud Computing, кроме всего прочего, удается решить проблему с разделением переменных окружения дочерними процессами, и самих данных в соседние процессы путем изоляции с помошью контейнеров.
3) при падении или компрометации отдельных компонент, взаимодействующих с внешним миром либо нет, тчень просто перезапустить или изолировать процесс и заменить его на другой
пароли устанавливает тот же человек, который настраивает пайплайн сборки, но не в скриптах, а в переменных окружения, используемых при сборке, взаимодействие узлов может осуществляеться в таком случает через использование пременных окружения из защифроманной памяти виртуальной машины (Google Cloud).
Нет, это завилит от конкретого pipeline, и CI, они настраиваются в конфигураторе конкретного CI, и фактически работают внутри контейнера, и могут располагаться как в облаке, так и на конкретной машине, на которой запущен агент CI, то есть это полностью зависит от того, как сконфигурирован конкретный агент (Azure, GitlLab, Jenkins позволяют установку локальных агентов не в облако а на конкретную машину, в зависимости от настроек агента, агент может либо требовать совместную настройку Docker-а, если работает в режиме ВМ, Docker/Docker Swarm ноды/ ноды кластера Kubertenes (GlitLab), либо нет, если работает в режиме remote shell, с прямым доступом к локальной оболочке ОС), так что с точки зрения Azure, GitHub и Google Cloud, происходит передача информации ("возьми пароль из переменной окружения x для подключения к БД у") вместо ("возьми пароль x для подключения к БД у")
Не будет, так так там будет светиться что-то вроде ${CI_GITLAB_PASSWORD}, а не пароль, а само значение ${CI_GITLAB_PASSWORD} можно забить как на источнике так и на целевой машине.
Я думаю, что стандартный, подход в DevOps заколючется как раз не в раскрытии приватной информации, с последующей ее защитой с помощью keyring, а в том, чтобы изначально параметризовать скрипты, (причем — любые: bash, powershell, python, Docker, и т.д.), с помощью настраиваемых переменных окружения, и предоставлении доступа к ним через Web IDE / Web UI и программный доступ по API для параметризации. Данный подход реализован в GitLab, Azure, Google Cloud, Digital Ocean, GitHub
Очевидно, что специалист тех.поддержки и есть фактически тот самый стрелочник, первой линии поддержки и общения с пользователями и заказчиками, который вынужден в силу низкого "социального" технического ранга отдуваться за ошибки и просчеты руководства, отдела маркетинга, тестирования, в более глобально — отсутствия культуры принятия решений в бизнесе. Всегда так было, не видел ни одного линейного руководителя, менеджера, который бы признал себя ущербным руководителем и указал на свои просчеты. Такое поведение, самоанализ больше свойственно для уровня CEO, глав подразделений, высшего менеджмента. Потому что именно неумение работать в команде и неумение учиться на чужих ошибках и выдвигают этих личностей на руководящие посты, это "пояс безопасности", который приводит в конечном счете к краху компании или стартапа. Безосновательная убежденность в правильности стратегии найма и управления персоналом, обычно приводит к "эффекту горизонта", и как следствие сужению горизонта планирования, операционного простора и снижения показателей эффективности бизнеса. Ставка на сильных управленцев и бюрократов в сочетании со "специалистами широкого профиля" — этот тот фатальный сценарий, который тормозит развитие, в силу менталитета, почти 100% инновационных российских компаний. Специалисты широкого профиля вынуждены таковыми становиться из-за низкой корпоративной культуры, а именно — страха быть уволенными, потерять работу из-за каких-то субъективных факторов (коррупция, кумовство, потеря целей), неспособности и нежелания бизнеса брать узких специалистов, умеющих работать в команде, распределять ответственность равномерно, умения доверять решению других специалистов. То есть сама система человеческих отношений, государственная политика и отсутствие живой конкуренции приводят к росту ожиданий работодателей, заказчиков и самих работников. В реальной жизни с низкой социальной поддержкой, низкокачественным медицинским обслуживанием, высокой часовой нагрузкой (будем честными, кто работает по 8 часов?), психологической перегрузкой (тех.поддержка правой рукой, создание "инновационного" продукта — левой) специалисты все чаще оказываются ситуации когда приходится делать выбор между высокой заработной платой и доступным свободным временем. А в результате страдают целые сектора высоких технологий, без преувеличения.
во многих сложных системах, безусловно, есть не только внутренние хосты, видимые со специально оговоренных IP-адресов, но и внешние, либо динамическим списком IP-адресов, вот в таком случае, велик шанс, что злоумышленнику, получившему валидную пару логин-пароль удастя получить контроль над БД на уровне сервиса, предроставляющего доступ извне, путем подмены IP-адреса, либо MTM, либо несколькими другими способами, (0-Day, и т.д.)
Конечно я использую изляцию Docker-a, например, eсли использовать, к примеру Google Cloud Computing + Docker, то очень быстно выяснится, что
1) вся ВМ, все диски, все свапы — шифруются,
2) при использовании Docker-a внутри Google Cloud Computing, кроме всего прочего, удается решить проблему с разделением переменных окружения дочерними процессами, и самих данных в соседние процессы путем изоляции с помошью контейнеров.
3) при падении или компрометации отдельных компонент, взаимодействующих с внешним миром либо нет, тчень просто перезапустить или изолировать процесс и заменить его на другой
пароли устанавливает тот же человек, который настраивает пайплайн сборки, но не в скриптах, а в переменных окружения, используемых при сборке, взаимодействие узлов может осуществляеться в таком случает через использование пременных окружения из защифроманной памяти виртуальной машины (Google Cloud).
Нет, это завилит от конкретого pipeline, и CI, они настраиваются в конфигураторе конкретного CI, и фактически работают внутри контейнера, и могут располагаться как в облаке, так и на конкретной машине, на которой запущен агент CI, то есть это полностью зависит от того, как сконфигурирован конкретный агент (Azure, GitlLab, Jenkins позволяют установку локальных агентов не в облако а на конкретную машину, в зависимости от настроек агента, агент может либо требовать совместную настройку Docker-а, если работает в режиме ВМ, Docker/Docker Swarm ноды/ ноды кластера Kubertenes (GlitLab), либо нет, если работает в режиме remote shell, с прямым доступом к локальной оболочке ОС), так что с точки зрения Azure, GitHub и Google Cloud, происходит передача информации ("возьми пароль из переменной окружения x для подключения к БД у") вместо ("возьми пароль x для подключения к БД у")
Пример (там есть пример настройки БД):
Testing a Phoenix application with GitLab CI/CD
Обрати внимение на
их можно заменить на переменные окружения
в переменных окружения для выполняемого процесса
Не будет, так так там будет светиться что-то вроде ${CI_GITLAB_PASSWORD}, а не пароль, а само значение ${CI_GITLAB_PASSWORD} можно забить как на источнике так и на целевой машине.
Я думаю, что стандартный, подход в DevOps заколючется как раз не в раскрытии приватной информации, с последующей ее защитой с помощью keyring, а в том, чтобы изначально параметризовать скрипты, (причем — любые: bash, powershell, python, Docker, и т.д.), с помощью настраиваемых переменных окружения, и предоставлении доступа к ним через Web IDE / Web UI и программный доступ по API для параметризации. Данный подход реализован в GitLab, Azure, Google Cloud, Digital Ocean, GitHub
Очевидно, что специалист тех.поддержки и есть фактически тот самый стрелочник, первой линии поддержки и общения с пользователями и заказчиками, который вынужден в силу низкого "социального" технического ранга отдуваться за ошибки и просчеты руководства, отдела маркетинга, тестирования, в более глобально — отсутствия культуры принятия решений в бизнесе. Всегда так было, не видел ни одного линейного руководителя, менеджера, который бы признал себя ущербным руководителем и указал на свои просчеты. Такое поведение, самоанализ больше свойственно для уровня CEO, глав подразделений, высшего менеджмента. Потому что именно неумение работать в команде и неумение учиться на чужих ошибках и выдвигают этих личностей на руководящие посты, это "пояс безопасности", который приводит в конечном счете к краху компании или стартапа. Безосновательная убежденность в правильности стратегии найма и управления персоналом, обычно приводит к "эффекту горизонта", и как следствие сужению горизонта планирования, операционного простора и снижения показателей эффективности бизнеса. Ставка на сильных управленцев и бюрократов в сочетании со "специалистами широкого профиля" — этот тот фатальный сценарий, который тормозит развитие, в силу менталитета, почти 100% инновационных российских компаний. Специалисты широкого профиля вынуждены таковыми становиться из-за низкой корпоративной культуры, а именно — страха быть уволенными, потерять работу из-за каких-то субъективных факторов (коррупция, кумовство, потеря целей), неспособности и нежелания бизнеса брать узких специалистов, умеющих работать в команде, распределять ответственность равномерно, умения доверять решению других специалистов. То есть сама система человеческих отношений, государственная политика и отсутствие живой конкуренции приводят к росту ожиданий работодателей, заказчиков и самих работников. В реальной жизни с низкой социальной поддержкой, низкокачественным медицинским обслуживанием, высокой часовой нагрузкой (будем честными, кто работает по 8 часов?), психологической перегрузкой (тех.поддержка правой рукой, создание "инновационного" продукта — левой) специалисты все чаще оказываются ситуации когда приходится делать выбор между высокой заработной платой и доступным свободным временем. А в результате страдают целые сектора высоких технологий, без преувеличения.
Тема не раскрыта. Хотелось больше услышать генетически управляемые нейронные сети. Тут вообще об этом ни слова.
По анимации, могу посоветовать вот эту часть (5) еще есть остальные 4 части