Назад | Перейти на главную страницу

Могу ли я смоделировать падение корзины S3, когда она доступна пользователю root?

Я пытаюсь протестировать новый код сетевого мониторинга для приложения, работающего на устройстве Debian. В настоящее время мне поручено обеспечить создание ловушки SNMP, когда внешние сетевые ресурсы (например, сегменты S3) монтируются с помощью FUSE и соединение разрывается.

Проблема в том, что для того, чтобы сделать общий ресурс недоступным, мне, по-видимому, пришлось бы сделать файлы недоступными для записи (или заблокировать все возможные IP-адреса, связанные с S3, с помощью iptables), и я не могу заблокировать доступ на запись, если сегмент предназначен для чтения и записи с помощью пользователь root и контролируется пользователем root.

Есть ли способ заставить эту программу, запущенную от имени root, думать, что корзина упала?

P.S. Я не могу создавать эти корзины с помощью chattr, потому что, черт возьми, S3 не поддерживает концепцию атрибутов, таких как неизменность.

Есть так много способов смоделировать что-то идущее вниз. Вы уже сказали, что нужно использовать правила блокировки iptables.

Другой действительно простой способ - отключить сетевой маршрутизатор, чтобы ваше программное обеспечение для мониторинга все еще могло видеть хост, но хост не мог разговаривать с S3 (или чем-либо еще в этом отношении). На мой взгляд, это самый простой вариант, но в некоторых случаях может не подходить.

Другой вариант - отредактировать файл hosts на сервере и добавить несколько фиктивных IP-адресов для имен хостов S3, чтобы они разрешались в неправильном месте. то есть использовать IP, который ничему не назначен. Поэтому все запросы S3 от хоста будут пытаться попасть туда, но не смогут. Когда вы закончите, просто удалите IP-адреса из файла hosts, и все вернется к жизни без перезагрузки.

Я не могу заблокировать доступ на запись, если корзина предназначена для чтения и записи пользователем root и контролируется пользователем root.

Эта история начинается и заканчивается тем, что к этой корзине нужно обращаться через IAM. Ваша корневая учетная запись в AWS существует только для настройки ролей IAM. После того, как вы настроили эту настройку, вы можете изменить привилегии IAM для тестирования.

Почему бы просто не проверить наличие определенного файла в корзине S3. Если его там нет, бросьте ловушку SNMP.

Создание / удаление этого файла упростит проверку правильности работы сценария.