О профилях Chef InSpec

[править на GitHub]

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

Структура профиля

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

examples/profile├── README.md├── controls│   ├── example.rb│   └── control_etc.rb├── libraries│   └── extension.rb|── files│   └── extras.conf└── inspec.yml

где:

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

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

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

inspec.yml

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

• Используйте name, чтобы указать уникальное имя для профиля. Необходимо.
• Используйте title, чтобы указать удобочитаемое имя для профиля.
• Используйте maintainer, чтобы указать автора профиля.
• Используйте copyright, чтобы указать держателя авторских прав.
• Используйте copyright_email, чтобы указать контактную информацию для поддержки профиля, обычно адрес электронной почты.
• Используйте license, чтобы указать лицензию для профиля.
• Используйте summary, чтобы указать краткое описание профиля в одной строке.
• Используйте description, чтобы указать многострочное описание профиля.
• Используйте version, чтобы указать версию профиля.
• Используйте inspec_version, чтобы установить ограничения SemVer на версию Chef InSpec, под которой может работать профиль.
• Используйте supports, чтобы указать список поддерживаемых целевых платформ.
• Используйте depends, чтобы определить список профилей, от которых зависит этот профиль.
• Используйте inputs, чтобы определить список входных данных, которые вы можете использовать в своих контролях.

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

name:sshtitle:Basic SSHmaintainer:Chef Software, Inc.copyright:Chef Software, Inc.copyright_email:support@chef.iolicense:Proprietary, All rights reservedsummary:Verify that SSH Server and SSH Client are configured securelyversion:1.0.0supports:- platform-family:linuxdepends:- name:profilepath:../path/to/profileinspec_version:"~> 2.1"

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

name:dummytitle:InSpec Profilemaintainer:The Authorscopyright:The Authorscopyright_email:you@example.comlicense:Apache-2.0summary:An InSpec Compliance Profileversion:0.1.0depends:- name:inheriturl:"https://artifactory.com/artifactory/example-repo-local/inspec/0.4.1.tar.gz"username:<%= ENV['USERNAME'] %>password:<%= ENV['API_KEY'] %>

Проверка профилей

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

inspec check examples/profile

Поддержка платформ

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

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

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

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

Например, для целей, работающих под Debian Linux, используйте:

name:sshsupports:- platform-name:debian

Для целей только Ubuntu версии 14.04 используйте:

name:sshsupports:- platform-name:ubunturelease:14.04

Для целей всего выпуска Ubuntu версии 14.x используйте:

name:sshsupports:- platform-name:ubunturelease:14.*

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

name:sshsupports:- platform-family:redhat

Для целей всего семейства платформы Windows 2019, включая Datcenter и Core Servers, используйте:

name:sshsupports:- platform-name:windows_server_2019*

Для целей любых, работающих на Amazon AWS, используйте:

name:sshsupports:- platform:aws

Для целей всех этих примеров в одном файле inspec.yml используйте:

name:sshsupports:- platform-name:debian- platform-name:ubunturelease:14.04- platform-family:redhat- platform:aws

Зависимости профилей

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

Для практических примеров ознакомьтесь с Создание пользовательского профиля Chef InSpec на Learn Chef Rally.

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

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

depends:- name:linux-baselineurl:https://github.com/dev-sec/linux-baseline/archive/master.tar.gz- name:ssh-baselineurl:https://github.com/dev-sec/ssh-baseline/archive/master.tar.gz

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

путь

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

depends:- name:my-profilepath:/absolute/path- name:anotherpath:../relative/path

url

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

depends:- name:my-profileurl:https://my.domain/path/to/profile.tgz- name:profile-via-giturl:https://github.com/myusername/myprofile-repo/archive/master.tar.gz

url также поддерживает аутентификацию по основанию.

depends:- name:my-profileurl:https://my.domain/path/to/profile.tgzusername:userpassword:password

git

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

depends:- name:git-profilegit:http://url/to/repobranch:desired_branchtag:desired_versioncommit:pinned_commitversion:semver_via_tagsrelative_path:relative/optional/path/to/profile

supermarket

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

Например:

depends:- name:supermarket-profilesupermarket:supermarket-username/supermarket-profile

Доступные профили Supermarket можно перечислить с помощью inspec supermarket profiles.

compliance

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

Например:

depends:- name:linuxcompliance:base/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
• baseline-1
• baseline-2

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

Пропуск контрольной точки из профиля

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

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

Изменение контрольной точки

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

При включении контрольной точки её также можно изменить!

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

Выборочное включение контрольных точек из профиля

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

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

• myapp-1
• myapp-2
• myapp-3
• baseline-2
• baseline-4

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

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

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

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

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

require_resource(profile: 'my_dep', resource:'my_res',as:'my_res2')

Это позволит вам обратиться к ресурсу my_res из профиля my_dep с помощью имени my_res2.

Входы профиля

Наша документация по Входным данным теперь находится на отдельной странице.

Файлы профиля

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

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

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

examples/profile├── controls│   ├── example.rb│── files│   └── services.yml└── inspec.yml

При этом services.yml содержит:

- service_name:httpd-alphaport:80- service_name:httpd-betaport:8080

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

my_services = yaml(content: inspec.profile.file('services.yml')).params

my_services.each do |s|
  describe service(s['service_name']) do
    it { should be_running }
end

describe port(s['port']) do
  it { should be_listening }
  end
end

Для более подробного примера использования файла профиля см. Ознакомление с ресурсами Chef InSpec на Learn Chef Rally.

Синтаксис “should” против “expect”

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

Chef InSpec продолжит поддерживать оба способа написания тестов. Рассмотрим этот file тест:

describe file('/tmp/test.txt') do
  it { should be_file }
end

Его можно переписать с синтаксисом expect

describe file('/tmp/test.txt') do
  it 'should be a file' do
    expect(subject).to(be_file)
  end
end

Вывод обоих приведенных выше примеров выглядит так:

File /tmp/test.txt
   ✔  should be a file

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

describe 'test file' do
  subject { file('/tmp/test.txt') }
  it 'should be a file' do
    expect(subject).to(be_file)
  end
end

… что приведет к следующему выводу:

test file
  ✔  should be a file