Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Контролировать качество исходного кода с самого старта жизненного цикла проекта - хорошая практика. Давайте разберемся, как применять этот принцип в работе с Kubernetes.
В целом, компании всегда ищут способы увеличить свою продуктивность на всех уровнях: инфраструктура, люди, процессы и др. Зачастую продуктивность достигается за счет внедрения автоматизированных процессов для облегчения работы и увеличения темпов производства. Подобная автоматизация требует эволюции, адаптации или даже полной трансформации концептов, используемых ранее. Это включает в себя обеспечение и контроль политик безопасности.
В самом деле, с появлением новых методов работы, основанных на гибкости (вроде DevOps), некоторые принципы безопасности пришлось адаптировать к темпам развития и управления компонентами инфраструктуры. Сегодня одна из наиболее безопасных практик - это как можно раньше переместить эти контрольные точки в цепи интеграции, чтобы быстрее обнаруживать любые аномалии, заслуживающие особого внимания.
Почему вам нужен подход Shift Left для обеспечения безопасности?
Термин “Shift Left” (“сдвиг влево”) введен в рамках методики DevSecOps для расширения сотрудничества между командами разработки, безопасности и администрирования. Идея в том, чтобы гарантировать безопасность приложения с самого начала цикла разработки, передвинув безопасность и тестирование влево на традиционном линейном представлении SDLC.
Этот метод уже много лет считается лучшей практикой разработки и, с момента появления методологии DevOps, получил широкое распространение за счет своей простоты в использовании и настройке, а также невероятных плюсов в условиях сотрудничества команд в комплексных проектах - таких как управление инфраструктурой с помощью Terraform, Ansible или Kubernetes.
Использование этих стандартов в обязательном порядке на уровне YAML-файла, а также на уровне их содержимого и конфигурации для облегчения чтения, внедрения и обслуживания - вот три концепции, которые любой проект сегодня должен стремиться реализовать.
Цель подхода Shift Left - разработка программного обеспечения с уже интегрированными лучшими практиками безопасности, чтобы обнаружить и решить возможные проблемы безопасности и уязвимости на как можно более раннем этапе процесса разработки. “Сдвиг влево” упрощает, ускоряет и делает более доступным решение проблем безопасности.
Как внедрить Shift Left?
Pre-commit - это инструмент командной строки с открытым исходным кодом, часть инструментария для сдвига определенных аспектов безопасности влево, за счет добавления автоматических контрольных точек после каждого коммита.
Это предоставляет возможность как можно раньше найти и контролировать любые аномалии в конвейере интеграции и вовремя сделать необходимые корректировки - до того как они попадут в релиз.
Чтобы этого добиться, необходимы три шага:
В вашей машине должен быть установлен Pre-commit
В корневой папке Git должен быть создан конфигурационный файл с именем “
.pre-commit-config.yaml”, и настроен с использованием hooksЧтобы автоматически вызывать команды на каждый коммит, Git-проект должен быть настроен локально
Важные соображения
Как вы могли понять из предыдущего раздела, команды pre-commit и Git проект необходимо настраивать локально, чтобы иметь возможность автоматического запуска. Это не та настройка, которая может быть принудительно установлена с удаленного устройства. Чтобы обеспечить ее применение необходим этап конфигурации проекта во время адаптации. Поэтому для распространения информации и обеспечения ее принятия требуется документация.
Тем не менее, в зависимости от контекста, можно автоматизировать использование этой технологии, разработав сценарий конфигурации среды (в данном случае - ноутбуков всех членов команды), или даже создать, поделиться и призвать команду использовать общий образ контейнера со всеми необходимыми инструментами разработки. Такая практика имеет множество преимуществ - в частности, при адаптации новых сотрудников путем минимизации необходимых действий для настройки окружения разработки.
Однако, если такой способ не применим, или кажется слишком сложным, всегда можно передвинуть эти элементы управления ниже по цепи интеграции, и таким образом автоматизировать их использование до развертывания.
Какие хуки можно использовать для управления ресурсами Kubernetes?
Данный раздел содержит список хуков доступных бесплатно и простых в установке и использовании с помощью Pre-Commit. Это очень субъективный список, который, очевидно, можно дополнить другими хуками в зависимости от контекста. Для простоты чтения мы добровольно сократили список до экосистемы Kubernetes.
Ниже список расширений Pre-Commit, полезных для проверки разработки и технического обслуживания ресурсов Kubernetes как можно раньше в конвейере интеграции:
Check-merge-conflict - для проверки конфликтов слияния до любого коммита
Trailing-whitespace - для очистки кода от бесполезного пустого пространства
Check-added-large-files - для контроля размера файлов? хранимых в вашем репозитории
End-of-file-fixer -для гарантии, что файлы заканчиваются новой строкой (и только новой строкой)
Yamllint - для автоматизации определения ошибок форматирования вашего кода перед каждым коммитом; очень важно для стандартизации кода и удобства его чтения
Yamlfix - для автоматизации коррекции форматирования
Checkov - для проверки соответствия файлов определений Kubernetes лучшим практикам разработки и пользовательским правилам
K8svalidate - для проверки соответствия файлов определений Kubernetes используемой версии Kubernetes
Detect-secrets - для определения любых конфиденциальных данных и предотвращения их хранения в коде
Большинство из этих хуков также подходят и для других случаев. В зависимости от сути проекта, некоторые хуки можно добавить для управления форматом файлов и их содержимым. Однако, держите под рукой краткий контрольный список, чтобы свести к минимуму их влияние на вашу производительность.
Вот конфигурационный файл Pre-Commit для быстрого теста этих хуков на вашем проекте Kubernetes:
---
repos:
- repo: https://github.com/adrienverge/yamllint.git
rev: v1.17.0
hooks:
- id: yamllint
args: [-c=.yamllint]
- repo: https://github.com/pre-commit/pre-commit-hooks
rev: v4.1.0
hooks:
- id: check-merge-conflict
- id: trailing-whitespace
- id: check-added-large-files
- id: end-of-file-fixer
- repo: https://github.com/bridgecrewio/checkov.git
rev: 2.0.975
hooks:
- id: checkov
args: [-d .]
- repo: https://github.com/Agilicus/pre-commit-hook-k8svalidate.git
rev: v0.0.8
hooks:
- id: k8svalidate
files: .yaml$
- repo: https://github.com/Yelp/detect-secrets
rev: v1.2.0
hooks:
- id: detect-secrets
Скопируйте содержимое этого файла и вставьте в файл с именем “.pre-commit-config.yaml” в корневой директории вашего проекта. Затем запустите команду pre-commit и получите результат!
Что же дальше?
В данной статье мы перечислили хуки Pre-Commit, полезные в повседневной работе для любого, кто администрирует один или более кластеров Kubernetes. Конечно, есть и другие, подходящие к совсем другим случаям. Например, DevOps-инженер заинтересуется расширением для управления настройками Prometheus и правилами форматирования или управления файлами Vagrant, и так далее.
Нет ограничений на то, что можно контролировать, но все еще необходимо оценивать влияние всех этих хуков на продуктивность сотрудника по сравнению с их преимуществами.
Больше информации про Pre-Commit можно найти по следующим ссылкам:
Pre-commit website·
Shift Left Security: Best Practices for Getting Started
Больше полезного из мира DevOps и DevSecOps - в нашем telegram-канале DevOps FM - присоединяйтесь, нас уже более тысячи)
