route_localnet=1 разрешает маршрутизацию пакетов, адресованных loopback интерфейсу (127.0.0.0/8). Например, в статье это используется для того, чтобы была возможность перенаправлять пакеты с 127.0.0.1:8000 на 10.100.0.2:8000.
iptables -t nat -A OUTPUT -p tcp -m addrtype --dst-type LOCAL -m tcp --dport 8000 -j DNAT --to-destination 10.100.0.2:8000
По поводу запрета стучаться одним контейнерам в другие. Во-первых, нужно убедиться, что они находятся в разных docker сетях. Во-вторых, добавить правила в firewall, запрещающие получение пакетов на хосте с bridge интерфейса (или со всех адресов подсети этого интерфейса) нужной вам докер сети по портам 80-8080. Пример:
Ценность HashiCorp Vault в том, что он позволяет централизовано хранить секреты и удобно управлять доступом к ним. И соответственно позволяет минимизировать появление таких ситуаций, когда секреты лежат в plain text'е, например, в каком-нибудь гит репозитории.
В случае с OTP ключами к ssh, Vault это не единственное решение, и не факт, что самое эффективное, но в случае если вы, к примеру, уже в инфраструктуре своего проекта храните секреты в кластере HashiCorp Vault (что сейчас совсем не редкость), то при необходимости внедрения системы одноразовых паролей для ваших машин, вам будет легче использовать Vault.
По поводу кражи токенов. Токен может утечь куда-нибудь, да. Для борьбы с такими ситуациями токену можно задать время жизни и кол-во использований. И в случае, если уже понятная утечка, то инвалидировать его.
В открытом виде генерацию OTP через API Vault лучше не отдавать сотрудникам на пользование. Лучше такое прятать за внутренний корпоративный сервис, где ты уже под своей корп учёткой запрашиваешь генерацию OTP к нужной машине. Соответственно access-token к vault'у хранится у сервиса.
Лично я предполагаю, что подобный генератор OTP для ssh будет полезен для автоматизации каких-либо работ на удалённых хостах, когда worker'у нужно один раз к чему-то подключиться, выполнить свои действия и потухнуть.
route_localnet=1разрешает маршрутизацию пакетов, адресованных loopback интерфейсу (127.0.0.0/8). Например, в статье это используется для того, чтобы была возможность перенаправлять пакеты с 127.0.0.1:8000 на 10.100.0.2:8000.По поводу запрета стучаться одним контейнерам в другие. Во-первых, нужно убедиться, что они находятся в разных docker сетях. Во-вторых, добавить правила в firewall, запрещающие получение пакетов на хосте с
bridgeинтерфейса (или со всех адресов подсети этого интерфейса) нужной вам докер сети по портам 80-8080. Пример:UPD: так как контейнеры за NAT, достаточно указать адрес маршрутизатора, то-есть адрес их
bridgeинтерфейса. Обновлённый пример:Один из вариантов использования, описанный в статье, это сетевая изоляция процессов) Решать, кто может им отправлять пакеты, и кому они могут.
Ценность HashiCorp Vault в том, что он позволяет централизовано хранить секреты и удобно управлять доступом к ним. И соответственно позволяет минимизировать появление таких ситуаций, когда секреты лежат в plain text'е, например, в каком-нибудь гит репозитории.
В случае с OTP ключами к ssh, Vault это не единственное решение, и не факт, что самое эффективное, но в случае если вы, к примеру, уже в инфраструктуре своего проекта храните секреты в кластере HashiCorp Vault (что сейчас совсем не редкость), то при необходимости внедрения системы одноразовых паролей для ваших машин, вам будет легче использовать Vault.
По поводу кражи токенов. Токен может утечь куда-нибудь, да. Для борьбы с такими ситуациями токену можно задать время жизни и кол-во использований. И в случае, если уже понятная утечка, то инвалидировать его.
В открытом виде генерацию OTP через API Vault лучше не отдавать сотрудникам на пользование. Лучше такое прятать за внутренний корпоративный сервис, где ты уже под своей корп учёткой запрашиваешь генерацию OTP к нужной машине. Соответственно access-token к vault'у хранится у сервиса.
Лично я предполагаю, что подобный генератор OTP для ssh будет полезен для автоматизации каких-либо работ на удалённых хостах, когда worker'у нужно один раз к чему-то подключиться, выполнить свои действия и потухнуть.
С clap и anyhow это я уже смухлевал) Там по сути жизненно необходим только parking_lot был
Хотелось по минимуму пользоваться сторонними библиотеками, и больше использовать функционал, который Rust предоставляет из коробки)