Аннотация ingress.class в 1.22 была объявлена как deprecated. https://kubernetes.io/blog/2021/07/14/upcoming-changes-in-kubernetes-1-22/ Честно говоря не понимаю практический смысл ручного поднятия куба. Если чисто для себя, есть уже замыленная статья "Kubernetes hard way" где всё описано. Есть kubespray который позволяет штамповать кластера под копирку и при этом можно легко добавлять/удалять ноды.
В документациях говорят о том, что решение с MetalB на балансировку api не совсем корректное: если будут какие-то проблемы с daemonset, то ip не поднимется и мы получим тыкву (c Ingress такая же история). В интернетах предлагаю решение kube-vip, которое запускается как static pod и позволяет перевозить ip между мастерами. Вот как это включается на kubespray https://github.com/kubernetes-sigs/kubespray/blob/master/docs/kube-vip.md
По идеи это как metalB, только static под на мастер-ноде, но считается, более надёжным
Даже в кубе кто-то эти CRD должен развернуть и настроить, если нет девопса на проекте то приётся кого-то просить с уважением и ждать. Пробежался по решению внешне выглядит как оператор vault и по мне лучше его и внедрить т.к. он более популярен. Но за решение спасибо, почитаю еще раз внимательнее
1) Как организовать версионирование секрета и откат/накат
2) Всё-таки где-то должны храниться исходные данные, которые вы помещаете в нужную среду
В случае если мы какие-то сторонние решения используем, то возникает вопрос их высокой доступности и кто их обслуживает. В случае хранения в репе обеспечение доступности сервиса лежит не нас.
По коммитам vault завезли "16 Jul 2020" я честно говоря пропустил этот момент, т.к. инструмент начал использовать гораздо раньше. KMS опять же не целевая архитектура для корпоратов: я долгое время работал в банке и внешние системы не рассматриваю. Спасибо, что указали на неточность, я в документации по sops вычитал интересную вещь: он может запушить секреты из файла в vault: sops publish $file
В случае helm secrets и sops все хранится в репе и ничего дополнительно не нужно. И потом можно разворачивать инфраструктурные решения и перезжать туда.
Келси Хайтауэр, ты ли это? Хотя это не важно — в любом случае будем рады увидеться 9 декабря на VK Kubernetes Conference: сможете поделиться своими знаниями с комьюнити
DL360 g5p 2012r2 встала без проблем. Были косяки с emulex'овскими hba-адаптерами, пришлось шить их, а потом поочереди накатывать дрова до последней версии (допер эмпирическим путем) производитель сказал, что они не будут работать с 2012 и дров на них нет.
Полтора года и ни единого разрыва :)
Авторизация из ad, но при подборе пароля блочится доступ на конкретный сервис, а не на вход в домен. Взять, например, exchange, защита от перебора паролей — блокировка учетки. Но счетчик попыток в данном случае ведет сам почтовый сервак и забанит вас он.
А атаки из серии, я запущу программу изнутри и она будет подбирать пароли маловероятна. Я подозреваю, что при включенном брандмауэре она ответ от dc даже не получит (соответственно схему мы не выгрузим).
Можно еще с пеной у рта кричать о software restriction policy и app controller, но лично мое мнение: в среднестатистической конторе нереально внедрять. (если кто внедрял, поделитесь опытом!!!)
По вашей статье предлагаю расширить область, рассмотрите как работает AD CS и какие проблемы позволяет решить.
радиус для железа хорош. Сейчас активно говорят о «притащи свое устройство», для этого есть workplace join, direct access. Они позволяют бурить тоннели через все подряд. И авторизироваться сертификатами. Формально ты за пределы сетевого периметра не выходишь.
https://habr.com/ru/company/ru_mts/blog/695242/ я в самом начале писал, про ingress canary. Istio тоже можно, но сложнее
"auth/approle/*" { capabilities = [ "create", "read", "update", "delete", "list" ] }path "sys/policies/acl/*" { capabilities = [ "create", "read", "update", "delete", "list" ] }Возможно я где-то что-то проглядел, но получается, что пользователь может сам себе политику поменять на любые права и забиндить любую роль.
А чем https://strimzi.io/ то не устроил ? Можно к его crd свой контроллер добавить и не пилить всё с нуля
Аннотация
ingress.classв 1.22 была объявлена как deprecated. https://kubernetes.io/blog/2021/07/14/upcoming-changes-in-kubernetes-1-22/ Честно говоря не понимаю практический смысл ручного поднятия куба. Если чисто для себя, есть уже замыленная статья "Kubernetes hard way" где всё описано. Есть kubespray который позволяет штамповать кластера под копирку и при этом можно легко добавлять/удалять ноды.В документациях говорят о том, что решение с MetalB на балансировку api не совсем корректное: если будут какие-то проблемы с daemonset, то ip не поднимется и мы получим тыкву (c Ingress такая же история). В интернетах предлагаю решение kube-vip, которое запускается как static pod и позволяет перевозить ip между мастерами. Вот как это включается на kubespray https://github.com/kubernetes-sigs/kubespray/blob/master/docs/kube-vip.md
По идеи это как metalB, только static под на мастер-ноде, но считается, более надёжным
Даже в кубе кто-то эти CRD должен развернуть и настроить, если нет девопса на проекте то приётся кого-то просить с уважением и ждать. Пробежался по решению внешне выглядит как оператор vault и по мне лучше его и внедрить т.к. он более популярен. Но за решение спасибо, почитаю еще раз внимательнее
Вижу несколько проблем:
1) Как организовать версионирование секрета и откат/накат
2) Всё-таки где-то должны храниться исходные данные, которые вы помещаете в нужную среду
В случае если мы какие-то сторонние решения используем, то возникает вопрос их высокой доступности и кто их обслуживает. В случае хранения в репе обеспечение доступности сервиса лежит не нас.
А где вы их храните и как они попадают в нужную среду ?
По коммитам vault завезли "16 Jul 2020" я честно говоря пропустил этот момент, т.к. инструмент начал использовать гораздо раньше. KMS опять же не целевая архитектура для корпоратов: я долгое время работал в банке и внешние системы не рассматриваю. Спасибо, что указали на неточность, я в документации по sops вычитал интересную вещь: он может запушить секреты из файла в vault:
sops publish $fileНапример, вы сидите в любой крупной корпоративной конторе и вам просто запрещено выносить что-либо за пределы контролируемой зоны.
В случае helm secrets и sops все хранится в репе и ничего дополнительно не нужно. И потом можно разворачивать инфраструктурные решения и перезжать туда.
Келси Хайтауэр, ты ли это? Хотя это не важно — в любом случае будем рады увидеться 9 декабря на VK Kubernetes Conference: сможете поделиться своими знаниями с комьюнити
Полтора года и ни единого разрыва :)
А атаки из серии, я запущу программу изнутри и она будет подбирать пароли маловероятна. Я подозреваю, что при включенном брандмауэре она ответ от dc даже не получит (соответственно схему мы не выгрузим).
Можно еще с пеной у рта кричать о software restriction policy и app controller, но лично мое мнение: в среднестатистической конторе нереально внедрять. (если кто внедрял, поделитесь опытом!!!)
По вашей статье предлагаю расширить область, рассмотрите как работает AD CS и какие проблемы позволяет решить.