Популярность облачных платформ и контейнеров растет с каждым днем. Вместе с этим появляется необходимость в активном контроле и защите используемых решений.
Есть много инструментов, которые могут сделать работу в K8s безопасной, а процессы — прозрачными и эффективными. Но в статье поговорим о самом недооцененном, но тем не менее актуальном способе для анализа безопасности в Kubernetes: о сборе Kube-Audit логов.
Совсем недавно разработчики, применяющие сканер образов Trivy, столкнулись с ошибкой TOOMANYREQUESTS. Она произошла из-за достижения максимального количества пользователей инструмента и предельной скорости по загрузкам из Container Registry (CR) ghcr.io.
Меня зовут Алиса Кириченко, я занимаюсь разработкой контейнерной платформы «Штурвал». Мы вовсю используем Trivy, но совсем не хотим зависеть от доступности сторонних сервисов. Иначе заказчики не поймут. Поэтому базы у нас свои, и обновляются они каждую ночь.
Если лень дальше читать, то вот, берите:
Trivy DB: public.shturval.tech/trivy-db
Trivy Java DB: public.shturval.tech/trivy-java-db
Детали — под катом.
Ни одно внедрение платформ для запуска контейнеризованных приложений в продуктивном контуре не должно обходиться без настройки логирования происходящих событий. В нашей платформе для управления контейнерами «Штурвал» для этих целей используется модуль OpenSearch.
На одном из проектов мне понадобилось настроить алертинг, чтобы администраторы k8s получали по электронной почте оповещение, если происходят те или иные события. Например, когда назначается ClusterRole с высоким уровнем доступа, при попытке запуска привилегированного контейнера или изменении конфигурации узла.
Изначально в кластере была настроена Audit Policy, определяющая, какие события должны записываться в журнал аудита и какие данные они должны содержать, а также Fluentbit Operator, отправляющий всё в OpenSearch. Кстати, подробнее о том, как мы настраиваем политику аудита в «Штурвале», я буду рассказывать 5 июня на конференции БеКон.
Казалось бы, дело за малым — изучить документацию и настроить алертинг, который доступен непосредственно в интерфейсе OpenSearch. Но этой статьи бы не было, если бы не дьявол, спрятавшийся в деталях.
С настройкой SMTP действительно не возникло никаких проблем, алертинг на нужные ресурсы тоже настраивался нативно. Но когда понадобилось вытащить данные из тела запроса и добавить их в отправляемое письмо, OpenSearch сказал, что «у него лапки». В открытых источниках я нашла множество тикетов без ответов или с сомнительными советами, которые не помогали решить проблему.
В итоге алертинг я настроила и попутно сделала инструкцию. Надеюсь, она будет для вас полезной.
Изменять конфигурацию узла Kubernetes нужно не только в момент создания кластера, но и при его обновлениях или изменениях в инфраструктуре. Хорошо, если узлы можно автоматизированно пересоздать или изменить без перезагрузки узла. А что делать, если такой возможности нет или количество узлов в кластере переваливает за сотню?
Меня зовут Александр Краснов, CTO компании «Лаборатория Числитель». Мы занимаемся разработкой программного обеспечения, создаем собственные продукты в области контейнерных платформ, DevOps, облачных решений и мониторинга. Я же проектирую и внедряю Kubernetes в Enterprise.
В основе этого поста — мой доклад с DevOps Conf 2023. Я расскажу про распространенные варианты управления конфигурацией кластеров с помощью Ansible, Cluster API и OpenShif Machine Config.
