#networkpolicy — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #networkpolicy, aggregated by home.social.
-
5 ошибок в NetworkPolicy, из‑за которых ваши политики ничего не блокируют
NetworkPolicy могут выглядеть корректно, применяться без ошибок и при этом оставлять кластер открытым там, где вы уверены в изоляции. Разберём пять типичных ошибок — от CNI без поддержки политик до неверных селекторов — и покажем, как проверять правила реальным трафиком, а не по наличию объектов в API.
https://habr.com/ru/companies/otus/articles/1067158/
#Kubernetes #NetworkPolicy #сетевые_политики #CNI #Calico #Cilium #ingress #egress #сетевая_изоляция #безопасность_Kubernetes
-
5 ошибок в NetworkPolicy, из‑за которых ваши политики ничего не блокируют
NetworkPolicy могут выглядеть корректно, применяться без ошибок и при этом оставлять кластер открытым там, где вы уверены в изоляции. Разберём пять типичных ошибок — от CNI без поддержки политик до неверных селекторов — и покажем, как проверять правила реальным трафиком, а не по наличию объектов в API.
https://habr.com/ru/companies/otus/articles/1067158/
#Kubernetes #NetworkPolicy #сетевые_политики #CNI #Calico #Cilium #ingress #egress #сетевая_изоляция #безопасность_Kubernetes
-
5 ошибок в NetworkPolicy, из‑за которых ваши политики ничего не блокируют
NetworkPolicy могут выглядеть корректно, применяться без ошибок и при этом оставлять кластер открытым там, где вы уверены в изоляции. Разберём пять типичных ошибок — от CNI без поддержки политик до неверных селекторов — и покажем, как проверять правила реальным трафиком, а не по наличию объектов в API.
https://habr.com/ru/companies/otus/articles/1067158/
#Kubernetes #NetworkPolicy #сетевые_политики #CNI #Calico #Cilium #ingress #egress #сетевая_изоляция #безопасность_Kubernetes
-
[Перевод] Kubernetes Multitenancy в 2026 году: как мы перестали поддерживать 30 кластеров и наконец сделали все правильно
«У нас тридцать два кластера». Руководитель команды platform engineering произнес это как на исповеди. Тридцать два. В компании с девятью продуктовыми командами. По шесть окружений на каждую. Никто не планировал такого — оно просто росло по одному кластеру за раз, каждый раз, когда команде требовалось что-то чуть иное, а самым простым ответом было «подними новый». Я слышала ту или иную версию этой фразы почти в каждой компании, достигшей определенного размера. Цифра меняется — иногда двенадцать, иногда шестьдесят, — но динамика всегда одна. Kubernetes легко позволяет создавать кластеры, никто намеренно не решал, когда их использовать совместно, а когда нет, и в какой-то момент кто-то смотрит на счет за облако и ротацию дежурств — и понимает, что управление десятками кластеров медленно пожирает платформенную команду заживо. Multitenancy — ответ на эту проблему. Kubernetes не был спроектирован для multitenancy из коробки, и, чтобы построить его правильно, требуются реальные инженерные инвестиции, но именно так зрелые команды platform engineering решают эту задачу в 2026 году — со все более удобным инструментарием и все лучше понятыми паттернами. Команда VK Cloud перевела статью, охватывающую все, что автор узнал о Kubernetes multitenancy в нескольких продакшен-окружениях: какие модели существуют, где каждая из них дает сбой, как выстроить слои изоляции, которые действительно защищают тенантов друг от друга, какие инструменты стоят вашего времени и как выглядит хорошо управляемый общий кластер на практике. Если ваша команда управляет слишком большим количеством кластеров или строит платформу для безопасного обслуживания нескольких команд — это руководство, которого мне так не хватало в начале пути.
https://habr.com/ru/companies/vktech/articles/1054016/
#vk_cloud #kubernetes #multitenancy #networkpolicy #vcluster #capsule #kyverno #finops #platformengineering #resourcequota
-
[Перевод] Kubernetes Multitenancy в 2026 году: как мы перестали поддерживать 30 кластеров и наконец сделали все правильно
«У нас тридцать два кластера». Руководитель команды platform engineering произнес это как на исповеди. Тридцать два. В компании с девятью продуктовыми командами. По шесть окружений на каждую. Никто не планировал такого — оно просто росло по одному кластеру за раз, каждый раз, когда команде требовалось что-то чуть иное, а самым простым ответом было «подними новый». Я слышала ту или иную версию этой фразы почти в каждой компании, достигшей определенного размера. Цифра меняется — иногда двенадцать, иногда шестьдесят, — но динамика всегда одна. Kubernetes легко позволяет создавать кластеры, никто намеренно не решал, когда их использовать совместно, а когда нет, и в какой-то момент кто-то смотрит на счет за облако и ротацию дежурств — и понимает, что управление десятками кластеров медленно пожирает платформенную команду заживо. Multitenancy — ответ на эту проблему. Kubernetes не был спроектирован для multitenancy из коробки, и, чтобы построить его правильно, требуются реальные инженерные инвестиции, но именно так зрелые команды platform engineering решают эту задачу в 2026 году — со все более удобным инструментарием и все лучше понятыми паттернами. Команда VK Cloud перевела статью, охватывающую все, что автор узнал о Kubernetes multitenancy в нескольких продакшен-окружениях: какие модели существуют, где каждая из них дает сбой, как выстроить слои изоляции, которые действительно защищают тенантов друг от друга, какие инструменты стоят вашего времени и как выглядит хорошо управляемый общий кластер на практике. Если ваша команда управляет слишком большим количеством кластеров или строит платформу для безопасного обслуживания нескольких команд — это руководство, которого мне так не хватало в начале пути.
https://habr.com/ru/companies/vktech/articles/1054016/
#vk_cloud #kubernetes #multitenancy #networkpolicy #vcluster #capsule #kyverno #finops #platformengineering #resourcequota
-
[Перевод] Kubernetes Multitenancy в 2026 году: как мы перестали поддерживать 30 кластеров и наконец сделали все правильно
«У нас тридцать два кластера». Руководитель команды platform engineering произнес это как на исповеди. Тридцать два. В компании с девятью продуктовыми командами. По шесть окружений на каждую. Никто не планировал такого — оно просто росло по одному кластеру за раз, каждый раз, когда команде требовалось что-то чуть иное, а самым простым ответом было «подними новый». Я слышала ту или иную версию этой фразы почти в каждой компании, достигшей определенного размера. Цифра меняется — иногда двенадцать, иногда шестьдесят, — но динамика всегда одна. Kubernetes легко позволяет создавать кластеры, никто намеренно не решал, когда их использовать совместно, а когда нет, и в какой-то момент кто-то смотрит на счет за облако и ротацию дежурств — и понимает, что управление десятками кластеров медленно пожирает платформенную команду заживо. Multitenancy — ответ на эту проблему. Kubernetes не был спроектирован для multitenancy из коробки, и, чтобы построить его правильно, требуются реальные инженерные инвестиции, но именно так зрелые команды platform engineering решают эту задачу в 2026 году — со все более удобным инструментарием и все лучше понятыми паттернами. Команда VK Cloud перевела статью, охватывающую все, что автор узнал о Kubernetes multitenancy в нескольких продакшен-окружениях: какие модели существуют, где каждая из них дает сбой, как выстроить слои изоляции, которые действительно защищают тенантов друг от друга, какие инструменты стоят вашего времени и как выглядит хорошо управляемый общий кластер на практике. Если ваша команда управляет слишком большим количеством кластеров или строит платформу для безопасного обслуживания нескольких команд — это руководство, которого мне так не хватало в начале пути.
https://habr.com/ru/companies/vktech/articles/1054016/
#vk_cloud #kubernetes #multitenancy #networkpolicy #vcluster #capsule #kyverno #finops #platformengineering #resourcequota
-
🤔 Oh, you're using #Squid 🦑 to control #Kubernetes egress? How delightfully retro! I'm sure your cluster will appreciate the walk down memory lane as it figures out what it's gossiping about behind your back. Just remember, it's not a real party until the #NetworkPolicy shows up and ruins the fun! 🎉
https://interlaye.red/kubernetes_002degress_002dsquid.html #Egress #RetroTech #CloudComputing #HackerNews #ngated -
🤔 Oh, you're using #Squid 🦑 to control #Kubernetes egress? How delightfully retro! I'm sure your cluster will appreciate the walk down memory lane as it figures out what it's gossiping about behind your back. Just remember, it's not a real party until the #NetworkPolicy shows up and ruins the fun! 🎉
https://interlaye.red/kubernetes_002degress_002dsquid.html #Egress #RetroTech #CloudComputing #HackerNews #ngated -
🤔 Oh, you're using #Squid 🦑 to control #Kubernetes egress? How delightfully retro! I'm sure your cluster will appreciate the walk down memory lane as it figures out what it's gossiping about behind your back. Just remember, it's not a real party until the #NetworkPolicy shows up and ruins the fun! 🎉
https://interlaye.red/kubernetes_002degress_002dsquid.html #Egress #RetroTech #CloudComputing #HackerNews #ngated -
🤔 Oh, you're using #Squid 🦑 to control #Kubernetes egress? How delightfully retro! I'm sure your cluster will appreciate the walk down memory lane as it figures out what it's gossiping about behind your back. Just remember, it's not a real party until the #NetworkPolicy shows up and ruins the fun! 🎉
https://interlaye.red/kubernetes_002degress_002dsquid.html #Egress #RetroTech #CloudComputing #HackerNews #ngated -
Công cụ Python mới giúp đánh giá nhanh bảo mật Kubernetes NetworkPolicy đã ra mắt! Nó cung cấp điểm số trực quan cho namespace, workload và cảnh báo về các chính sách không an toàn. Đây là bản MVP, tác giả rất mong nhận được phản hồi để cải thiện.
#Kubernetes #NetworkPolicy #Security #Python #Tool #BảoMật #CôngCụ
https://www.reddit.com/r/SideProject/comments/1orlpsg/i_built_a_python_tool_to_quickly_evaluate/
-
Mình 개발 công cụ Python đánh giá an ninh Kubernetes NetworkPolicy nhanh. Cung cấp điểm tư duy và gợi ý chính sách không an toàn. MVP────—ocket cùng mình partager! facebook.com/SaSa0011/policyshield #Kubernetes #NetworkPolicy #PythonTool #CôngTừPython #CyberSecurity
https://www.reddit.com/r/SaaS/comments/1orlnd8/i_built_a_python_tool_to_quickly_evaluate/
-
Безопасность Kubernetes-кластеров: вредные советы или bullshit bingo
Как погубить кластер, действуя во благо? Подборка вредных советов из реальных кейсов и опыта от специалиста по безопасности контейнеров и Kubernetes. Вместе установим антивирус на ноды, просканируем хостовую ОС и заблокируем выкатки образов с чувствительной информацией. Привет, Хабр! Меня зовут Дмитрий Евдокимов. Я — Founder & CTO Luntry в компании по созданию решений для безопасности контейнеров и Kubernetes, CFP конференций DevOpsConf и Highload, автор курса «Cloud-Native безопасность в Kubernetes» и телеграм-канала k8s (in) security. Эта статья написана по мотивам моего доклада для DevOpsConf 2024. Так как я проработал в сфере информационной безопасности больше 15 лет и специализируюсь именно на безопасности контейнеров и кластеров, дам несколько «вредных» советов, как сделать Kubernetes-кластер «безопасным». Погубить кластер
https://habr.com/ru/companies/oleg-bunin/articles/875114/
#кубернетес #контейнеры #оркестрация_микросервисов #окружение #shift_left_security #уязвимости #distroless #zerotrust #NetworkPolicy #apparmor
-
Безопасность Kubernetes-кластеров: вредные советы или bullshit bingo
Как погубить кластер, действуя во благо? Подборка вредных советов из реальных кейсов и опыта от специалиста по безопасности контейнеров и Kubernetes. Вместе установим антивирус на ноды, просканируем хостовую ОС и заблокируем выкатки образов с чувствительной информацией. Привет, Хабр! Меня зовут Дмитрий Евдокимов. Я — Founder & CTO Luntry в компании по созданию решений для безопасности контейнеров и Kubernetes, CFP конференций DevOpsConf и Highload, автор курса «Cloud-Native безопасность в Kubernetes» и телеграм-канала k8s (in) security. Эта статья написана по мотивам моего доклада для DevOpsConf 2024. Так как я проработал в сфере информационной безопасности больше 15 лет и специализируюсь именно на безопасности контейнеров и кластеров, дам несколько «вредных» советов, как сделать Kubernetes-кластер «безопасным». Погубить кластер
https://habr.com/ru/companies/oleg-bunin/articles/875114/
#кубернетес #контейнеры #оркестрация_микросервисов #окружение #shift_left_security #уязвимости #distroless #zerotrust #NetworkPolicy #apparmor
-
Безопасность Kubernetes-кластеров: вредные советы или bullshit bingo
Как погубить кластер, действуя во благо? Подборка вредных советов из реальных кейсов и опыта от специалиста по безопасности контейнеров и Kubernetes. Вместе установим антивирус на ноды, просканируем хостовую ОС и заблокируем выкатки образов с чувствительной информацией. Привет, Хабр! Меня зовут Дмитрий Евдокимов. Я — Founder & CTO Luntry в компании по созданию решений для безопасности контейнеров и Kubernetes, CFP конференций DevOpsConf и Highload, автор курса «Cloud-Native безопасность в Kubernetes» и телеграм-канала k8s (in) security. Эта статья написана по мотивам моего доклада для DevOpsConf 2024. Так как я проработал в сфере информационной безопасности больше 15 лет и специализируюсь именно на безопасности контейнеров и кластеров, дам несколько «вредных» советов, как сделать Kubernetes-кластер «безопасным». Погубить кластер
https://habr.com/ru/companies/oleg-bunin/articles/875114/
#кубернетес #контейнеры #оркестрация_микросервисов #окружение #shift_left_security #уязвимости #distroless #zerotrust #NetworkPolicy #apparmor
-
An interesting article on #kubernetes networking
https://otterize.com/blog/mastering-kubernetes-networking-otterize-s-journey-in-cloud-native-packet-management -
Ever fought to write a Kubernetes network policy? Well, while it may be hard to write straight to YAML, here is a graphical tool that writes YAML for you.
-
Ever fought to write a Kubernetes network policy? Well, while it may be hard to write straight to YAML, here is a graphical tool that writes YAML for you.
-
Ever fought to write a Kubernetes network policy? Well, while it may be hard to write straight to YAML, here is a graphical tool that writes YAML for you.
-
Today's adventure in #darkpattern #surveillance comes from #Grafana #Loki. (Not a surprise, but this is why I run egress filters and dns #adblock in my #homelab clusters.)
I know not everyone agrees that #optout #telemetry is a dark pattern, but you might agree with me about this one after you see it documented:
> # -- Optional analytics configuration
> analytics: {}Enlightening, isn't it? There are other empty blocks, but they are either fairly standard or are described elsewhere in the document.
If you are familiar with #helm, you won't despair because you have the power of `analytics.enabled: false`. That works on the rest of this chart and is the standard way to en/disable things.
It doesn't work that way.
Let me save you some time with the terrible new #github code search. Here is the actual syntax:
"analytics.reporting_enabled: false"This was caught by #adguard and enforced by an egress #networkpolicy
-
Today's adventure in #darkpattern #surveillance comes from #Grafana #Loki. (Not a surprise, but this is why I run egress filters and dns #adblock in my #homelab clusters.)
I know not everyone agrees that #optout #telemetry is a dark pattern, but you might agree with me about this one after you see it documented:
> # -- Optional analytics configuration
> analytics: {}Enlightening, isn't it? There are other empty blocks, but they are either fairly standard or are described elsewhere in the document.
If you are familiar with #helm, you won't despair because you have the power of `analytics.enabled: false`. That works on the rest of this chart and is the standard way to en/disable things.
It doesn't work that way.
Let me save you some time with the terrible new #github code search. Here is the actual syntax:
"analytics.reporting_enabled: false"This was caught by #adguard and enforced by an egress #networkpolicy
-
Today's adventure in #darkpattern #surveillance comes from #Grafana #Loki. (Not a surprise, but this is why I run egress filters and dns #adblock in my #homelab clusters.)
I know not everyone agrees that #optout #telemetry is a dark pattern, but you might agree with me about this one after you see it documented:
> # -- Optional analytics configuration
> analytics: {}Enlightening, isn't it? There are other empty blocks, but they are either fairly standard or are described elsewhere in the document.
If you are familiar with #helm, you won't despair because you have the power of `analytics.enabled: false`. That works on the rest of this chart and is the standard way to en/disable things.
It doesn't work that way.
Let me save you some time with the terrible new #github code search. Here is the actual syntax:
"analytics.reporting_enabled: false"This was caught by #adguard and enforced by an egress #networkpolicy
-
Today's adventure in #darkpattern #surveillance comes from #Grafana #Loki. (Not a surprise, but this is why I run egress filters and dns #adblock in my #homelab clusters.)
I know not everyone agrees that #optout #telemetry is a dark pattern, but you might agree with me about this one after you see it documented:
> # -- Optional analytics configuration
> analytics: {}Enlightening, isn't it? There are other empty blocks, but they are either fairly standard or are described elsewhere in the document.
If you are familiar with #helm, you won't despair because you have the power of `analytics.enabled: false`. That works on the rest of this chart and is the standard way to en/disable things.
It doesn't work that way.
Let me save you some time with the terrible new #github code search. Here is the actual syntax:
"analytics.reporting_enabled: false"This was caught by #adguard and enforced by an egress #networkpolicy
-
Today's adventure in #darkpattern #surveillance comes from #Grafana #Loki. (Not a surprise, but this is why I run egress filters and dns #adblock in my #homelab clusters.)
I know not everyone agrees that #optout #telemetry is a dark pattern, but you might agree with me about this one after you see it documented:
> # -- Optional analytics configuration
> analytics: {}Enlightening, isn't it? There are other empty blocks, but they are either fairly standard or are described elsewhere in the document.
If you are familiar with #helm, you won't despair because you have the power of `analytics.enabled: false`. That works on the rest of this chart and is the standard way to en/disable things.
It doesn't work that way.
Let me save you some time with the terrible new #github code search. Here is the actual syntax:
"analytics.reporting_enabled: false"This was caught by #adguard and enforced by an egress #networkpolicy
