curl http://mytestdomain.com

тобишь выйти из сетки кубера, из сетки амазона и зайти обратно

сейчас попробую, я не помню точно, какой ответ я получал

curl падает по таймауту

а mtr ничего не выдает кроме интернал адреса ноды

curl http://mytestdomain.com

.

# mtr traefik.k8s.example.com -c2 --report Start: 2018-12-03T15:14:32+0000 HOST: test-597c957468-7n8fc Loss% Snt Last Avg Best Wrst StDev 1.|-- ip-10-10-1-220.eu-west-1. 0.0% 2 0.0 0.1 0.0 0.1 0.0 2.|-- ??? 100.0 2 0.0 0.0 0.0 0.0 0.0

это из поды запущенной ручками

curl -H 'mydomain.com' http://EXTERNAL_NODE_IP

минуту

аналогично. а хотя стоп

там еще балансировщик

сейчас поковыряюсь.

похоже что проблема в лоадбалансере

так и есть

я не мог с ноды пойти на балансировщик

т.к. кластер доступен только через впн. добавил ноды в секьюрити группу и все завелось

https://github.com/kubernetes/dashboard/wiki/Accessing-Dashboard---1.7.X-and-above#kubectl-proxy - следуя докам, почему dashboard не доступен извне? Выставил NodePort(master), запустил proxy, но сайт unreachable

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

он был нужен, когда волт не поддерживал авторизацию через кубер

Авторизация через кубер тоже так себе затея, сервис аккаунт токен пересылается волту целиком

можно использовать аккаунт только для авторизации в vault. У меня так и сделано

Если все делать аккуратно и в волт засылать только безправные аккаунты то норм, но следить придется

ценность данных в волте больше, чем в кубере. Если не доверять волту, то зачем его использовать?

но критика правильная, не могу не согласиться

не сильно надеюсь, что переделают механизм авторизации в кубере

Деплою cloudbees core. Сделал nfs шару, могу делать на нее PVC через volumeClaimTemplates. Но теперь выпадает другая ошибка: Normal SuccessfulCreate 68m statefulset-controller create Claim sfs-name-cce333-cjoc-0 Pod cjoc-0 in StatefulSet cjoc success Warning FailedCreate 3m24s (x149 over 68m) statefulset-controller create Pod cjoc-0 in StatefulSet cjoc failed error: Pod "cjoc-0" is invalid: spec.containers[0].volumeMounts[0].name: Not found: "jenkins-home"

не могу понять, это надо в StatefulSet править?

можно использовать аккаунт только для авторизации в vault. У меня так и сделано

ну т.е. получается воркфлов такой: при помощи vault kubernetes auth в контейнер прокидывается токен(куб-токен). Дальше приложение напрямую или через инит контейнер при помощи этого токена сначала аутентифицируется и потом уже получает нужный секрет. При этом сервис аккаунт кубера привязывается к необходимой роли и полиси в волте. Схема такая? или какие-то нюансы…

некоторые просто используют vault kubernetes auth + approle. Наример: https://medium.com/ww-engineering/working-with-vault-secrets-on-kubernetes-fde381137d88 но как-то грань между целесообразной необходимость и оверинженерингом… она как бы тонка и лично мне не очевидна

ценность данных в волте больше, чем в кубере. Если не доверять волту, то зачем его использовать?

Ну, знать секреты и возможность их применить не обязательно связаны. Даже очень хорошо бы, чтоб они были вообще разнесены :) по-этому всякие динамические создания пользователей в AWS хороши, только при фильтрации по URL , чтобы давать доступ только к iam.amazonaws.com , иначе в одном месте слишком много доверия концентрируется

ну т.е. получается воркфлов такой: при помощи vault kubernetes auth в контейнер прокидывается токен(куб-токен). Дальше приложение напрямую или через инит контейнер при помощи этого токена сначала аутентифицируется и потом уже получает нужный секрет. При этом сервис аккаунт кубера привязывается к необходимой роли и полиси в волте. Схема такая? или какие-то нюансы…

Нюанс в том, что хорошо б чтобы токен отсылаемый в волт вообще никаких прав не имел нигде, кроме самого волта

https://github.com/kubernetes/kubernetes/issues/71411 #решето

https://github.com/kubernetes/kubernetes/issues/71411 #решето

Так исправили же ж

еще бы, если б неисправили мы бы и не узнали

зато любителям посидеть на стабильных 1.7 и .9 будет приятный сюрприз

https://github.com/kubernetes/kubernetes/issues/71411 #решето

"In default configurations, all users (authenticated and unauthenticated) are allowed to perform discovery API calls that allow this escalation." Блджад. Это что за запросы такие?

зато любителям посидеть на стабильных 1.7 и .9 будет приятный сюрприз

У них агрегации нет же, а proxy/exec кому попало не дают

У них агрегации нет же, а proxy/exec кому попало не дают

с метрикссервером будет агрегация

хотя случай редкий

с метрикссервером будет агрегация

Она ж в 1.10 появилась? Или я проспал

Она ж в 1.10 появилась? Или я проспал

интерфейс был с 1.7 (туда же service catalog), просто обычно для этого пользовались хипстером, а на нем, похоже, это не проявляется

https://github.com/kubernetes/kubernetes/issues/71411 #решето

А чего так не патриотично? Вот правильная ссылка https://www.redhat.com/en/blog/kubernetes-privilege-escalation-flaw-innovation-still-needs-it-security-expertise

А чего так не патриотично? Вот правильная ссылка https://www.redhat.com/en/blog/kubernetes-privilege-escalation-flaw-innovation-still-needs-it-security-expertise

аа, ну да, там лого и смешное видео

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

Ребят, а нет инструмента для спецификации и деплоя пулов с нодами в GCE? Чтоб было достаточно поправить yaml файл и сделать что-то вроде kubectl apply -f spec.

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

надеюсь, скоро откроют страницу в MITRE и прикрепят репродьюсер, но кратко - открывается вебсокет, насколько я понял, от имени прокси - и если клиент коннект не закрыл то его можно использовать снова. Вот тут немного написано - https://github.com/rancher/rancher/issues/14931#issuecomment-434939122

соответственно фикс в том чтобы не ждать закрытия коннекта, а закрывать его самим если там HTTP 101

Господа, а что бы автоматически передеплоивать docker-images, при обновление в hub.docker нужно использовать https://github.com/v2tec/watchtower ? А Swarm это получается не умеет делать? K8S+helm вроде говорят что может, но ведь он “стрельба по воробям”, если у меня дешевая VPS и 5 сервисов (k8s все ресурсы будет сжирать)?

Господа, а что бы автоматически передеплоивать docker-images, при обновление в hub.docker нужно использовать https://github.com/v2tec/watchtower ? А Swarm это получается не умеет делать? K8S+helm вроде говорят что может, но ведь он “стрельба по воробям”, если у меня дешевая VPS и 5 сервисов (k8s все ресурсы будет сжирать)?

беги от swarm, юзай nomad. Образ лучше обновлять через ci/cd, используй gitlab.com. А вообще это чат k8s only

надеюсь, скоро откроют страницу в MITRE и прикрепят репродьюсер, но кратко - открывается вебсокет, насколько я понял, от имени прокси - и если клиент коннект не закрыл то его можно использовать снова. Вот тут немного написано - https://github.com/rancher/rancher/issues/14931#issuecomment-434939122

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

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

ага, насколько я понял, да

Нюанс в том, что хорошо б чтобы токен отсылаемый в волт вообще никаких прав не имел нигде, кроме самого волта

ну в контейнер же монтируется JWT токен сервис аккаунта, который кладется в /run/secrets/kubernetes.io/serviceaccount/token. При помощи этого токена логинишся в волт и уже получаешь заветный “секрет на доступ к секретам” т.е. токен. Поидее дело должно быть “шито-крыто”, но нюансов я не знаю…

ну в контейнер же монтируется JWT токен сервис аккаунта, который кладется в /run/secrets/kubernetes.io/serviceaccount/token. При помощи этого токена логинишся в волт и уже получаешь заветный “секрет на доступ к секретам” т.е. токен. Поидее дело должно быть “шито-крыто”, но нюансов я не знаю…

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

Применить к чему? Можете пожалуйста расширить ответ. Ну или ссылку где это можно почитать

тоже не уловил. Что может делать токен, описывается же маппингом сервис аккаунта в роль и полиси волта

Видел в кубе патчи замержили, где от сервис аккаунтов будут отходить в пользу уникального токена на каждый под. Но когда это случится не понятно

да вотож…все в целом очень запутанно, и через пол года не хочется перехерачивать почти с нуля

Применить к чему? Можете пожалуйста расширить ответ. Ну или ссылку где это можно почитать

Скомпрометированный волт может сходить в куб и удалить все поды :)

Аааа, тю. Ну да.

беги от swarm, юзай nomad. Образ лучше обновлять через ci/cd, используй gitlab.com. А вообще это чат k8s only

А кубер в этом случае оверкил?

Скомпрометированный волт может сходить в куб и удалить все поды :)

Спасибо

до него еще надо добраться =) Ну и иногда скомпрометированный волт это уже самое плохое что могло случиться.

А кубер в этом случае оверкил?

~2GB и 1cpu на пустой месте плюс минус. Не считая сложностей в общем.

А кубер в этом случае оверкил?

в гугле можно кубер на одной ноде, еще какой-нибудь preemptible. Если планируется рост, можно подумать. Иначе сложность не стоит вложений времени.

я бы тоже плюсанул за номад для такой задачи.

в гугле можно кубер на одной ноде, еще какой-нибудь preemptible. Если планируется рост, можно подумать. Иначе сложность не стоит вложений времени.

Зачем на одной ноде, да ещё и preemptive?

автор вопроса хостит свои контейнеры на vps. Оверкил бывает не только по сложности, но и по деньгам.

до него еще надо добраться =) Ну и иногда скомпрометированный волт это уже самое плохое что могло случиться.

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

автор вопроса хостит свои контейнеры на vps. Оверкил бывает не только по сложности, но и по деньгам.

этого я не понял. В чем оверкил по хостингу контейнера на vps?

нивчем. Минимально

нивчем. Минимально

make && make install?

ну т.е. если у чела есть впс с докером, то кубер на одной ноде - это плюс минус не на много отличается по деньгам. (Если очень хочется). А то народ любит задавать вопросы вне контекста, мол зачем на одной ноде. Есть деньги - делай HA, нет вопросов.

куб даёт kubectl apply -f это 10 из 10. Даже HA не так важно.

жалко что ноды так пока не разворачиваются

swarm тоже это даёт, только это боль.

жалко что ноды так пока не разворачиваются

kubespray же

это не то

максимально близко

ваще ни разу

у kubectl нет ансиболи внутри