О профилях 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 версии 20.04 используйте:

name:sshsupports:- platform-name:ubunturelease:20.04

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

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

Для указания платформ Red Hat и производных, таких как CentOS и Oracle Linux, используйте:

name:sshsupports:- platform-family:redhat

Для указания всего семейства платформ Windows 2019, включая Datacenter и 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:20.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-адресу. Профиль должен быть доступен через операцию 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 также поддерживает аутентификацию по протоколу basic.

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 указывает профиль, расположенный на сервере 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” vs. “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