О профилях Chef InSpec

  1. inspec.yml
  2. Проверить профили
  3. Определение зависимостей
  4. дорожка
  5. URL
  6. мерзавец
  7. супермаркет
  8. соблюдение
  9. Зависимости от вендоров
  10. Использование элементов управления из включенного профиля
  11. Включая все элементы управления из профиля
  12. Пропуск элемента управления из профиля
  13. Изменение элемента управления
  14. Выборочное включение элементов управления из профиля
  15. Использование ресурсов из включенного профиля
  16. Установка атрибутов во внешнем файле атрибутов YAML
  17. Приоритет значения атрибута

Chef InSpec поддерживает создание сложных профилей тестирования и соответствия, которые организуют элементы управления для поддержки управления зависимостями и повторного использования кода. Каждый профиль представляет собой отдельную структуру со своим собственным потоком распространения и выполнения.

Профиль должен иметь следующую структуру:

examples / profile ├── README.md controls── элементы управления │ ├── example.rb │ └── control_etc.rb ├── библиотеки │ └── extension.rb | ── файлы │ └── extras.conf └ ── inspec.yml

где:

  • inspec.yml включает описание профиля (обязательно)
  • control - это каталог, в котором находятся все тесты (обязательно)
  • библиотеки - это каталог, в котором расположены все расширения ресурсов Chef InSpec (необязательно)
  • файлы - это каталог с дополнительными файлами, к которым профиль может получить доступ (необязательно)
  • README.md должен использоваться, чтобы объяснить профиль, его область и использование

См. Полный пример профиля в репозитории Chef InSpec с открытым исходным кодом: Пример профиля Chef InSpec

Также проверьте Изучите ресурсы Chef InSpec на Learn Chef Rally, чтобы узнать больше о том, как профили структурированы с практическими примерами.

inspec.yml

Каждый профиль должен иметь файл inspec.yml, который определяет следующую информацию:

  • Используйте имя, чтобы указать уникальное имя для профиля. Необходимые.
  • Используйте заголовок, чтобы указать удобочитаемое имя для профиля.
  • Используйте сопровождающего, чтобы указать сопровождающего профиля.
  • Используйте авторское право, чтобы указать правообладателя.
  • Используйте copyright_email, чтобы указать контактную информацию службы поддержки для профиля, как правило, адрес электронной почты.
  • Используйте лицензию, чтобы указать лицензию для профиля.
  • Используйте сводку, чтобы указать однострочное резюме для профиля.
  • Используйте описание, чтобы указать многострочное описание профиля.
  • Используйте версию, чтобы указать версию профиля.
  • Используйте inspec_version для наложения ограничений SemVer на версию Chef InSpec, под которой может работать профиль.
  • Используйте опоры, чтобы указать список поддерживаемых целей платформы.
  • Использование зависит, чтобы определить список профилей, от которых зависит этот профиль.
  • Используйте атрибуты, чтобы определить список атрибутов, которые вы можете использовать в своих элементах управления.

имя обязательно; все остальные настройки профиля являются необязательными. Например:

name: ssh title: Базовый сопровождающий SSH: Chef Software, Inc. авторское право: Chef Software, Inc. copyright_email: [email protected] лицензия: проприетарная, все права защищены. сводка: убедитесь, что SSH-сервер и SSH-клиент настроены надежно, версия: 1.0 .0 поддерживает: - семейство os: linux зависит: - имя: путь к профилю: ../path/to/profile inspec_version: "~> 2.1"

Inspec.yml также поддерживает встроенный ERB в файле. Например:

имя: фиктивное название: сопровождающий профиля InSpec: авторские права авторов: авторские права copyright_email: [email protected] лицензия: сводка Apache-2.0: версия профиля соответствия InSpec: 0.1.0 зависит: - имя: наследовать URL: "https: / /artifactory.com/artifactory/example-repo-local/inspec/0.4.1.tar.gz "имя пользователя: <% = ENV ['USERNAME']%> пароль: <% = ENV ['API_KEY']%>

Проверить профили

Используйте команду inspec check, чтобы проверить реализацию профиля:

$ inspec проверить примеры / профиль

Используйте параметр support в файле inspec.yml, чтобы указать одну (или несколько) платформ, для которых предназначен профиль. Список поддерживаемых платформ может содержать следующее:

  • Используйте platform-family, чтобы ограничиться определенным семейством платформ.
  • Используйте имя платформы, чтобы ограничить конкретное имя платформы.
  • Используйте release для ограничения конкретной версией платформы (используется с platform-name).
  • Используйте платформу, чтобы ограничить или имя платформы или семейство платформ.

Для совместимости мы поддерживаем os-name и os-family. Мы рекомендуем всем пользователям сменить os-name на platform-name, а os-family на platform-family.

С Chef InSpec 2.0 мы представили новые семейства, которые помогут отличить облачные платформы. Новые семейства могут ограничивать семейство платформ os, aws, azure или gcp.

Например, чтобы нацелить что-либо под управлением Debian Linux:

имя: ssh поддерживает: - имя платформы: debian

и предназначаться только для Ubuntu версии 14.04

имя: ssh поддерживает: - имя платформы: версия Ubuntu: 14.04

и предназначаться для всей платформы RedHat (включая CentOS и Oracle Linux):

имя: ssh поддерживает: - платформа-семья: redhat

и нацелить что-либо, работающее на Amazon AWS:

имя: ssh поддерживает: - платформа: aws

и нацелить все эти примеры в одном файле inspec.yml:

имя: ssh поддерживает: - имя-платформы: debian - имя-платформы: выпуск ubuntu: 14.04 - семейство платформ: redhat - платформа: aws

Профиль Chef InSpec может использовать элементы управления и пользовательские ресурсы из другого профиля Chef InSpec. Кроме того, при наследовании элементов управления другого профиля профиль может пропускать или даже изменять эти включенные элементы управления.

Для практических примеров, проверьте Создайте собственный профиль Chef InSpec на Учебное ралли шеф-повара.

Определение зависимостей

Прежде чем профиль сможет использовать элементы управления из другого профиля, необходимо указать профиль для включения в файл inspec.yml включаемого профиля в разделе зависимостей. Для каждого включаемого профиля должно быть указано место для профиля, откуда его нужно получить, и имя для профиля. Например:

зависит от: - name: linux-baseline url: https://github.com/dev-sec/linux-baseline/archive/master.tar.gz - name: ssh-baseline url: https://github.com/dev -сек / SSH-базовый / архив / master.tar.gz

Chef InSpec поддерживает несколько источников зависимостей.

дорожка

Параметр пути определяет профиль, который находится на диске. Этот параметр обычно используется при разработке профилей и при отладке профилей.

зависит: - имя: путь к моему профилю: / absolute / path - имя: другой путь: ../relative/path

URL

Параметр url указывает профиль, который расположен по URL-адресу HTTP или HTTPS. Профиль должен быть доступен через операцию HTTP GET и должен быть действительным архивом профиля (в формате zip, tar или tar.gz).

зависит: - имя: URL-адрес моего профиля: https: //my.domain/path/to/profile.tgz - имя: URL-адрес профиля через git: https://github.com/myusername/myprofile-repo/archive /master.tar.gz

URL также поддерживает базовую аутентификацию.

зависит: - имя: URL моего профиля: https: //my.domain/path/to/profile.tgz имя пользователя: пароль пользователя: пароль

мерзавец

Параметр git указывает профиль, который находится в репозитории git, с дополнительными параметрами для ветви, тега, фиксации и версии. Местоположение источника переводится в URL после разрешения. Этот тип зависимостей поддерживает ограничения версий посредством семантического контроля версий в виде тегов git.

Например:

зависит: - имя: git-профиль git: http: // url / to / repo ветка: требуемый_ответ тега: требуемая версия фиксация: pinned_commit версия: semver_via_tags

супермаркет

Параметр супермаркета указывает профиль, который находится в кулинарной книге, размещенной в супермаркете Chef. Местоположение источника переводится в URL после разрешения.

Например:

зависит: - имя: супермаркет-профиль супермаркет: супермаркет-имя пользователя / супермаркет-профиль

Доступные профили супермаркетов могут быть перечислены с профилями супермаркетов inspec.

соблюдение

Параметр соответствия указывает профиль, который находится на сервере Chef Automate или Chef Compliance.

Например:

зависит: - имя: соответствие Linux: база / Linux

Зависимости от вендоров

Когда вы выполняете локальный профиль, файл inspec.yml будет считан для того, чтобы определить любые зависимости профиля. Затем он будет локально кэшировать зависимости и сгенерирует файл inspec.lock.

Если вы добавляете или обновляете зависимости в inspec.yml, зависимости могут быть перепроданы, а файл блокировки обновлен с помощью inspec vendor --overwrite

Использование элементов управления из включенного профиля

После определения в inspec.yml можно использовать элементы управления из включенных профилей! Давайте посмотрим на некоторые примеры.

Включая все элементы управления из профиля

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

В приведенном выше примере каждый раз, когда выполняется my-app-profile, все элементы управления из my-baseline также выполняются. Следовательно, будут выполнены следующие элементы управления:

  • MyApp-1
  • MyApp-2
  • MyApp-3
  • Базовый-1
  • Базовый-2

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

Пропуск элемента управления из профиля

Что если один из элементов управления из включенного профиля не применяется к вашей среде? К счастью, нет необходимости сохранять слегка измененную копию включенного профиля только для удаления элемента управления. Команда skip_control указывает Chef InSpec не запускать определенный элемент управления.

В приведенном выше примере все элементы управления из профиля my-app-profile и my-baseline будут выполняться каждый раз, когда выполняется my-app-profile, за исключением элемента управления baseline-2 из профиля my-baseline.

Изменение элемента управления

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

Когда элемент управления включен, он также может быть изменен!

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

В приведенном выше примере все элементы управления из my-baseline выполняются вместе со всеми элементами управления из включающего профиля my-app-profile. Тем не менее, в случае отказа базового уровня 1, он будет повышен с воздействием 0,5 вместо первоначально запланированного воздействия 1,0.

Выборочное включение элементов управления из профиля

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

Каждый раз, когда выполняется my-app-profile, в дополнение к собственным элементам управления, он запускает только элементы управления, указанные в блоке require_controls. В этом случае будут выполнены следующие элементы управления:

  • MyApp-1
  • MyApp-2
  • MyApp-3
  • Базовый-2
  • Базовый-4

Элементы управления baseline-1, baseline-3 и baseline-5 не будут выполняться, как если бы они были пропущены вручную. Этот метод включения определенных элементов управления обеспечивает выполнение только указанных элементов управления; если новые элементы управления будут добавлены в более позднюю версию my-baseline, они не будут запущены.

И так же, как это возможно изменить элементы управления при использовании include_controls, элементы управления также могут быть изменены.

И так же, как это возможно изменить элементы управления при использовании include_controls, элементы управления также могут быть изменены

Как и в предыдущем примере, выполняются только baseline-2 и baseline-4, но если baseline-2 завершится неудачно, он сообщит с воздействием 0,5 вместо первоначально запланированного воздействия 1,0.

Использование ресурсов из включенного профиля

По умолчанию все настраиваемые ресурсы из указанной зависимости доступны для использования в вашем профиле. Если две ваши зависимости предоставляют ресурс с одним и тем же именем, вы можете использовать DSL-функцию require_resource для устранения неоднозначности:

require_resource (профиль: 'my_dep', ресурс: 'my_res', as: 'my_res2')

Это позволит вам ссылаться на ресурс my_res из профиля my_dep, используя имя my_res2.

Атрибуты часто используются для параметризации профиля для использования в различных средах или целях. Он также может использоваться для определения секретов, таких как имена пользователей и пароли, которые иначе не должны храниться в виде простого текста в кулинарной книге. Атрибуты могут быть установлены для всего профиля в inspec.yml.

Атрибуты могут содержать следующие параметры:

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

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

атрибуты: - имя: тип пользователя: строковое значение: боб

Пример добавления объекта массива серверов:

атрибуты: - имя: тип сервера: значение массива: - сервер1 - сервер2 - сервер3

Для доступа к атрибуту вы будете использовать ключевое слово атрибута. Вы можете использовать это где угодно в вашем контрольном коде.

Например:

current_user = атрибут ('user') управляет 'system-users' действительно описывают атрибут ('user'), делают это {должен eq 'bob'} end описывают current_user делают это {должен eq attribute ('user')} end end

Установка атрибутов во внешнем файле атрибутов YAML

Для конфиденциальных данных рекомендуется использовать файл YAML, расположенный на локальном компьютере, для заполнения значений атрибутов. Чтобы прочитать значения из файла YAML, используйте команду run inspec exec и укажите путь к этому файлу YAML с помощью атрибута --attrs.

Например, файл метаданных вашего профиля, inspec.yml:

атрибуты: - имя: тип имени пользователя: обязательная строка: true - имя: тип пароля: обязательная строка: true

Контроль:

control 'system-users' do влиять на 0.8 desc 'Этот тест проверяет, что пользователь "Bob" установил пользователя в системе вместе с указанным паролем. «описать атрибут (« имя пользователя ») сделать это {должен eq« bob »} конец описать атрибут (« пароль ») сделать это {следует eq« секретный »} конец конец

И YAML-файл с именем profile-attribute.yml:

имя пользователя: боб пароль: секрет

Следующая команда запускает тесты и применяет секреты, указанные в profile-attribute.yml:

$ inspec exec examples / profile-attribute --attrs examples / profile-attribute.yml

Чтобы изменить свои атрибуты для конкретных платформ, вы можете настроить несколько файлов --attrs.

Например, inspec.yml:

атрибуты: - имя: тип пользователя: обязательный массив: true

YAML-файл с именем windows.yml

пользователи: - Администратор - Гость - Рэнди

Файл YAML с именем linux.yml

пользователи: - root - shadow - rmadison

Контрольный файл:

контроль 'системные пользователи' влияют на 0,8 дес 'Подтвердите, что в системе созданы надлежащие пользователи' опишите пользователей, которые делают это ('usernames') {should eq attribute ('users')} end end

Следующая команда запускает тесты и применяет указанные атрибуты:

$ inspec exec examples / атрибут-профиля --atatrs examples / windows.yml $ inspec exec примеры / атрибут-профиля --attrs examples / linux.yml

Смотрите полный пример в репозитории Chef InSpec с открытым исходным кодом: Пример профиля InSpec Chef с атрибутами

Приоритет значения атрибута

Значения атрибута всегда устанавливаются в следующем порядке (от наивысшего к низшему):

  1. Значения из файла, указанного в командной строке с помощью –attrs
  2. Значения из файла метаданных профиля - inspec.yml с атрибутами: раздел
  3. Значения, предоставляемые непосредственно в управляющем коде - атрибут («пользователь», значение: «Боб»)

Профиль Chef InSpec может содержать дополнительные файлы, к которым можно получить доступ во время тестов. Файл профиля позволяет вам отделить логику ваших тестов от данных, которые проверяют ваши тесты, например, список портов, которые вам необходимо открыть.

Чтобы получить доступ к этим файлам, они должны храниться в каталоге файлов в корне профиля. Доступ к ним осуществляется по их имени относительно этой папки с помощью inspec.profile.file (...).

Вот пример для чтения и тестирования списка портов. Структура папок:

examples / profile controls── контролирует │ ├── example.rb │── файлы │ └── services.yml └── inspec.yml

С services.yml, содержащим:

- имя_службы: порт httpd-alpha: 80 - имя_службы: порт httpd-beta: 8080

Тесты в example.rb теперь могут получить доступ к этому файлу:

my_services = yaml (content: inspec.profile.file ('services.yml')). params my_services.each do | s | описать службу (s ['имя_службы']) сделать это {следует be_running} конец описать службу (s ['порт']) сделать это {следует be_listening} конец конец

Для более полного примера, который использует файл профиля, см. Изучите ресурсы Chef InSpec на Учебное ралли шеф-повара.

Пользователи, знакомые с инфраструктурой тестирования RSpec, могут знать, что есть два способа написания тестовых операторов: следует и ожидайте. Сообщество RSpec решило, что ожидаемый является предпочтительным синтаксисом. Тем не менее, Chef InSpec рекомендует синтаксис must, так как он более удобен для чтения тем пользователям, которые не являются техническими.

Шеф-повар InSpec продолжит поддерживать оба метода написания тестов. Рассмотрим этот файл теста:

описать файл ('/ tmp / test.txt') сделать это {следует be_file} конец

Это может быть переписано с ожидаемым синтаксисом

описать файл ('/ tmp / test.txt') сделать это 'должен быть файл' действительно ожидать (субъект) .to (be_file) конец конец

Вывод обоих приведенных выше примеров выглядит следующим образом:

Файл /tmp/test.txt ✔ должен быть файлом

Кроме того, вы можете использовать ключевое слово subject для дальнейшего контроля выходных данных, если вы решите:

опишите 'test file' do subject {file ('/ tmp / test.txt')} это 'должен быть файл' do Ожидайте (subject) .to (be_file) конец конец

… Который выдаст следующий вывод:

тестовый файл ✔ должен быть файлом

Возможно, тест еще должен быть запущен, но если он не пройден, его следует рассматривать как низкий уровень серьезности, а не высокий уровень серьезности?