Size: a a a

DevSecOps - русскоговорящее сообщество

2020 July 26

DD

Dmitriy Dazm in DevSecOps - русскоговорящее сообщество
Окружение видимо, енв - environment ?
источник

RR

Roman Rusakov in DevSecOps - русскоговорящее сообщество
а, да, сори
источник

RR

Roman Rusakov in DevSecOps - русскоговорящее сообщество
окружение
источник

RR

Roman Rusakov in DevSecOps - русскоговорящее сообщество
что то типа why do you need to filter egress traffic in your environment
источник

DD

Denis Denisov in DevSecOps - русскоговорящее сообщество
Ну вдруг)
источник

DD

Denis Denisov in DevSecOps - русскоговорящее сообщество
Microservices Security in Action

Brief content:
- Microservices security landscape
- First steps in securing microservices
- Securing north/south traffic with an API gateway
- Accessing a secured microservice via a single-page application
- Engaging throttling, monitoring, and access control
- Securing east/west traffic with certificates
- Securing east/west traffic with JWT
- Securing east/west traffic over gRPC
- Securing reactive microservices
- Conquering container security with Docker
- Securing microservices on Kubernetes
- Securing microservices with Istio service mesh
- Secure coding practices and automation

#literature #k8s #docker
источник

DD

Denis Denisov in DevSecOps - русскоговорящее сообщество
Сегодня только нашел
источник

S

St in DevSecOps - русскоговорящее сообщество
В кубере без фильтрации на выход не обойтись, чаще всего
источник

S

St in DevSecOps - русскоговорящее сообщество
Ну и тут больше риски для той инфраструктуры,  куда доступ с кубера предоставляется
источник

GG

George Gaál in DevSecOps - русскоговорящее сообщество
Denis Denisov
Microservices Security in Action

Brief content:
- Microservices security landscape
- First steps in securing microservices
- Securing north/south traffic with an API gateway
- Accessing a secured microservice via a single-page application
- Engaging throttling, monitoring, and access control
- Securing east/west traffic with certificates
- Securing east/west traffic with JWT
- Securing east/west traffic over gRPC
- Securing reactive microservices
- Conquering container security with Docker
- Securing microservices on Kubernetes
- Securing microservices with Istio service mesh
- Secure coding practices and automation

#literature #k8s #docker
Такое ощущение, что все сводится к двум тезисам
источник

GG

George Gaál in DevSecOps - русскоговорящее сообщество
1. Кубер - это для самописных сервисов.
2. Используйте истио
источник

GG

George Gaál in DevSecOps - русскоговорящее сообщество
St
Ну и тут больше риски для той инфраструктуры,  куда доступ с кубера предоставляется
Мы с ИБ это обсуждали. Для них кубер - это облачко на схеме, где может быть что угодно. А без нормальных acl на корневых коммутаторах они не хотят
источник

S

St in DevSecOps - русскоговорящее сообщество
George Gaál
Мы с ИБ это обсуждали. Для них кубер - это облачко на схеме, где может быть что угодно. А без нормальных acl на корневых коммутаторах они не хотят
Я сам с ИБ и сам проходил этот вопрос пару лет назад))
источник

GG

George Gaál in DevSecOps - русскоговорящее сообщество
Остаётся только договариваться, просвещать. Внедрять network policies. Опеншифт со своим cni или истио, матьего
источник

С

Сергей in DevSecOps - русскоговорящее сообщество
Мы, как ИБ, советуем внедрять принцип минимальных привилегий через dependency management сразу: чтобы сервис явно указывал в виде зависимостей, куда он ходит, включая другие сервисы, БД и т.п.
источник

A

Anton in DevSecOps - русскоговорящее сообщество
Сергей
Мы, как ИБ, советуем внедрять принцип минимальных привилегий через dependency management сразу: чтобы сервис явно указывал в виде зависимостей, куда он ходит, включая другие сервисы, БД и т.п.
как то это визуализируете? документируете?
источник

S

St in DevSecOps - русскоговорящее сообщество
Вообще кроме как прибивать ip к подам по другому не получится фильтровать,  либо использовать l7 fw
источник

GG

George Gaál in DevSecOps - русскоговорящее сообщество
Сергей
Мы, как ИБ, советуем внедрять принцип минимальных привилегий через dependency management сразу: чтобы сервис явно указывал в виде зависимостей, куда он ходит, включая другие сервисы, БД и т.п.
Это должно быть не на уровне "этот айпи" в "этот айпи", а на уровне выше "сервис а в сервис б"
источник

GG

George Gaál in DevSecOps - русскоговорящее сообщество
И пускай это на уровне ниже преобразуется в правила файрволла - учитывая, что среда полностью динамичная
источник

С

Сергей in DevSecOps - русскоговорящее сообщество
Anton
как то это визуализируете? документируете?
Визуализируем пока никак, только начинаем эту историю. Документация - общая для всех сервисов, у них у каждого свой мини-манифест, где они указывают свои требования к кубернетесу типа env, реусрвов и т.п.
источник