Ещё про небезопасный AI)
Задача - запустить трафик в k8s с Istio через egress для 2 интеграций. Плюс egress отвечает за SSL origination. Обязательное условие: маршруты должны быть отдельными - порты и все манифесты.
Агент меня понял, обсудили делали, он написал спецификацию на основе моих вводных.
Вычитываю спецификацию... 2 VirtualService, 2 ServiceEntry... Вроде все ок. И вдруг - 2 ergress?!? Вопрос агенту - что это? Ответ: ну ты же просил разделить маршруты. Плюс у каждого маршрута в теории свои сертификаты, и т.об. мы физически разграничили доступ к ним.
Даже наша кибербеза никогда не была такой безопасной)
Агента удалось переубедить вопросом: интересно, с таким подходом - отдельный прокси на порт - сколько миллионов проксей в Google?)
Ладно, это скорее курьез. Но вот еще пример. Когда проектировали интеграцию с Vault агент предложил для каждого клиента - приклад и egress - сделать свой ServiceAccount. Развести по разным пользователям по сути. Ровно по той же причине - разграничить доступ к секретам. Кто до такого уровня безопасности доходил?)
Идея, кстати, хорошая, но есть минус - нужно прописывать все эти кастомные ServiceAccount в Vault. С default проще.
И вишенка на торте - агент не только предложил установить права на файл секрета 400 (это база), но ещё и на каталог с секретом 700 поставить. А в прикладе проверить эти права! Т.е такими правами мы запрещаем удаление и создание нового секрета каким-то взломанным sidecar-ом. Круто!
Но есть же ещё родительский каталог - /vault/secrets в случае Vault. И если там есть права на запись - уязвимость остаётся? Нет - в прикладе предлагается ещё и owner секрета проверять. А т.к у нас естественно runAsNonRoot: true и запрет повышения привилегий (это тоже база), то сменить пользователя невозможно. И если все сайдкары кроме Vault запускать под другим пользователем - подмену сразу будет видно.
P.S. Проверять за агентом конечно же нужно в любом случае
#ai
Задача - запустить трафик в k8s с Istio через egress для 2 интеграций. Плюс egress отвечает за SSL origination. Обязательное условие: маршруты должны быть отдельными - порты и все манифесты.
Агент меня понял, обсудили делали, он написал спецификацию на основе моих вводных.
Вычитываю спецификацию... 2 VirtualService, 2 ServiceEntry... Вроде все ок. И вдруг - 2 ergress?!? Вопрос агенту - что это? Ответ: ну ты же просил разделить маршруты. Плюс у каждого маршрута в теории свои сертификаты, и т.об. мы физически разграничили доступ к ним.
Даже наша кибербеза никогда не была такой безопасной)
Агента удалось переубедить вопросом: интересно, с таким подходом - отдельный прокси на порт - сколько миллионов проксей в Google?)
Ладно, это скорее курьез. Но вот еще пример. Когда проектировали интеграцию с Vault агент предложил для каждого клиента - приклад и egress - сделать свой ServiceAccount. Развести по разным пользователям по сути. Ровно по той же причине - разграничить доступ к секретам. Кто до такого уровня безопасности доходил?)
Идея, кстати, хорошая, но есть минус - нужно прописывать все эти кастомные ServiceAccount в Vault. С default проще.
И вишенка на торте - агент не только предложил установить права на файл секрета 400 (это база), но ещё и на каталог с секретом 700 поставить. А в прикладе проверить эти права! Т.е такими правами мы запрещаем удаление и создание нового секрета каким-то взломанным sidecar-ом. Круто!
Но есть же ещё родительский каталог - /vault/secrets в случае Vault. И если там есть права на запись - уязвимость остаётся? Нет - в прикладе предлагается ещё и owner секрета проверять. А т.к у нас естественно runAsNonRoot: true и запрет повышения привилегий (это тоже база), то сменить пользователя невозможно. И если все сайдкары кроме Vault запускать под другим пользователем - подмену сразу будет видно.
P.S. Проверять за агентом конечно же нужно в любом случае
#ai