Все ему так доверяют, будто он десяток аудитов выдержал

да и не в мир же его открывать..

как ты узнаешь что “нас ломают” и пора жать на кнопку? =)

Где детали то? Патч какой то странный , руками читают из сокета код ошибки. Интересно увидеть технические подробности

ну т.е. ты распознал реальный взлом или попытки взломов? попытки взломов идут тысячами ежедневно…. распознать реальный взлом уже веселее. Правда интересно. Помню, у нас(давно) на нагиосе была алертилка на новые открытые порты на хостинг серверах…но это в другую эпоху

https://www.redhat.com/en/blog/understanding-critical-kubernetes-privilege-escalation-flaw-openshift-3 побольше деталей

Хм, > When connecting to the kubelet, the API Server uses certificate based authentication Там же у kubelet webhook Auth с недавних пор, когда на каждый запрос он ходит обратно в apiserver и проверяет можно ли

это если --authorization-mode=Webhook, по идее это спасет от такого

В issue написано что ничего не поможет, только отключение portforward/exec , значит вебхук тоже обходят или он не такой надёжный как обещали :)

Всем привет, натолкните на мысль, ставлю node-exporter к prom’у, в namespace prometheus desired node_exporter=0, если поднимать в namespace kube-system, все нормально взлетает. prometheus ставил просто манифестами. https://pastebin.com/eqQPRYX3

Остался мой вопрос без внимания, кто-нибудь сталкивался?

в kubernetes можно получить количество запросов к сервису как метрику? хочу использовать для hpa

после ковыряний, остановился на деплойменте istio (оно мне всё равно надо будет) - оно добавляет пром с метрикой istio_requests_total, которую можно привязать к Deployment, и использовать для hpa. Второй вариант - использовать метрику envoy_cluster_upstream_rq_total которую можно привязать к подам

а сталкивался ли кто-то что такоей вот ингрес по умолчанию перекидывает на https, чего мне не нужно apiVersion: extensions/v1beta1 kind: Ingress metadata: name: frontend-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - http: paths: - path: / backend: serviceName: frontend servicePort: 80

Прямо редиректит?

а сталкивался ли кто-то что такоей вот ингрес по умолчанию перекидывает на https, чего мне не нужно apiVersion: extensions/v1beta1 kind: Ingress metadata: name: frontend-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - http: paths: - path: / backend: serviceName: frontend servicePort: 80

А если на порт сервиса сходить? В обход ингресса?

на любом ingress-controller это должно быть. На nginx nginx_ingress_controller_requests.

а сталкивался ли кто-то что такоей вот ингрес по умолчанию перекидывает на https, чего мне не нужно apiVersion: extensions/v1beta1 kind: Ingress metadata: name: frontend-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - http: paths: - path: / backend: serviceName: frontend servicePort: 80

https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#server-side-https-enforcement-through-redirect

"By default the controller redirects (308) to HTTPS if TLS is enabled for that ingress"

нашел, было именно в этом: annotations: nginx.ingress.kubernetes.io/rewrite-target: / nginx.ingress.kubernetes.io/ssl-redirect: "false"

тут вопрос в том, как эту метрику привязать к deployment. Один ингресс может раскидывать запросы на разные бэкенды

🔵 В группе есть традиция - представляться при входе: ▫️Какой у вас проект или где работаете? ▫️В чём вы специалист? ▫️Чем можете быть интересны или полезны сообществу? ▫️Чем интересно сообщество вам? ▫️Откуда вы? ▫️Как узнали про группу? В сообщении нужно указать тэг #whois 🔵 Правила чата: 🚫 Публикация вакансий запрещена 🚫 Реклама запрещена 🚫 Политика запрещена 🚫 Флуд и непрофессиональное поведение запрещено За несоблюдение правил - одно предупреждение, далее следует бан. Вакансии и запросы на поиск работы публикуем в группе @devops_jobs. Формат любой: full-time, part-time, remote и разовые подработки. Также обмениваемся инсайдами и аналитикой по рынку труда. Здесь общаемся на темы, посвященные Docker и экосистеме. Задаем вопросы, решаем проблемы и делимся новостями. Параллельно с этой группой развивается: 🔸@docker_ru - посвященная Docker, Docker Swarm и экосистеме в целом. Задаём вопросы, обсуждаем идеи, решаем проблемы, делимся новостями и т.д. 🔸@devops_ru - активно общаемся на темы, посвященные DevOps, Docker, Mesos, DC/OS, CoreOS, Clouds и т.д. 📡 Возможно, вам также будут интересны группы: @nodejs_ru, @react_js, @angular_js, @javascript_jobs, @reactnative_ru, @ios_ru, @android_ru, @mobile_jobs. Приятного общения!

label, то есть?

ingress="gitlab" - вижу. А вот какой service в качестве бэкенда будет - нет

У вас был редирект фолс? Или это после правки стал таким?

спасибо, подумаю над этим вариантом тоже, хотя мне наверное всё равно istio надо будет

если у вас десятки микросервисов и у каждого своя команда - то напрягать всех ради автоскейлинга интегрироваться, а потом всё равно ставить в кубер адаптеры, такое себе решение

если у вас десятки микросервисов и у каждого своя команда - то напрягать всех ради автоскейлинга интегрироваться, а потом всё равно ставить в кубер адаптеры, такое себе решение

Блин, всегда одно и тоже)) "а чего это мы должны теперь брать параметры из энвов" "зачем нам ваш докер, и так же все работает". Блин, да потому что. Потому что так это работает и работает эффективнее. А если вам откровенно лень ходить и всех попинывать, то так и напишите - мне тупо лень, а не пытайтесь переложить эту проблему на сложность технологии или ее реализации ;)

если всё делать по хорошему, это всё равно должен быть отвязанный сервис на другом порту, который отдаёт метрики независимо от возможно задыхающегося приложения

А Кафка и зукипер в одном поде это ок?

А зачем их держать в одном поде?