Анализ PostgreSQL с помощью InSpec в Ubuntu 18.04

4 мая, 2019 11:55 дп 805 views | Комментариев нет

InSpec – это автоматизированная среда тестирования с открытым исходным кодом для аудита системы; ее целью является обеспечение соответствия требованиям интеграции, безопасности и другим политикам. Разработчики могут проверить фактическое состояние своей инфраструктуры и приложений на соответствие целевому состоянию с помощью InSpec.

Чтобы определить условия политики, которым должно соответствовать приложение, InSpec предлагает средства контроля аудита. Традиционно разработчики указывают требования вручную и часто делают это прямо перед развертыванием изменений в рабочей среде. Однако с InSpec разработчики могут непрерывно оценивать соответствие приложения на каждом этапе разработки продукта, что помогает в решении проблем на ранних этапах разработки. InSpec DSL (Domain Specific Language), построенный на RSpec (это инструмент тестирования DSL, написанный на Ruby), определяет синтаксис, используемый для написания элементов контроля аудита.

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

В этом мануале вы научитесь устанавливать InSpec на сервер Ubuntu 18.04. Для начала мы напишем тест, который проверяет семейство операционных систем сервера, а затем создадим профиль аудита PostgreSQL с нуля. Этот профиль сначала проверяет, установлен ли PostgreSQL и запущены ли его сервисы. Затем нужно добавить другие тесты, чтобы убедиться, что сервис PostgreSQL работает по правильному порту, адресу, протоколу и через нужного пользователя. Вы научитесь тестировать отдельные параметры конфигурации PostgreSQL и проверять настройки аутентификации клиента.

Требования

Сервер Ubuntu 18.04, настроенный по этому мануалу.
Рабочая установка PostgreSQL 10 (читайте мануал Установка и использование PostgreSQL в Ubuntu 18.04).

1: Установка InSpec

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

Перейдите в свой домашний каталог:

cd ~

Загрузите файл:

curl -LO https://packages.chef.io/files/stable/inspec/3.7.11/ubuntu/18.04/inspec_3.7.11-1<^>_amd64.deb

Затем с помощью команды sha256sum создайте контрольную сумму загруженного файла. Это необходимо для проверки его целостности и подлинности.

sha256sum inspec_3.7.11-1_amd64.deb

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

e665948f9c0441e8648b08f8d3c8d34a86f9e994609877a7e4853c012dbc7523 inspec_3.7.11-1_amd64.deb

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

Далее нужно установить загруженный бинарный файл. Для этого можно использовать команду dpkg (она предназначена для управления пакетами и по умолчанию поставляется со всеми системами на основе Debian, к которым относится и Ubuntu). Флаг -i предлагает команде dpkg установить файлы.

sudo dpkg -i inspec_3.7.11-1_amd64.deb

Если ошибок на экране нет, значит, вы успешно установили InSpec. Чтобы проверить установку, введите следующую команду:

inspec version

В полученном выводе будет указана версия InSpec, которую вы только что установили:

3.7.11

Если номер версии не отображается, выполните раздел 1 с самого начала.

После этого вы можете удалить файл inspec_3.7.11-1_amd64.deb, поскольку он вам больше не нужен:

rm inspec_3.7.11-1_amd64.deb

Вы успешно установили InSpec на свой сервер.

2: Первый тест InSpec

Теперь попробуйте пройти свой первый тест InSpec, который проверит, относится ли ваша операционная система к семейству Debian.

Используйте ресурс os (это встроенный ресурс аудита InSpec) для тестирования платформы, на которой работает система. Также нужно использовать сопоставитель eq. Это универсальный сопоставитель, который проверяет точное равенство двух значений.

Тест InSpec состоит из блока describe, который содержит один или несколько операторов it и its, каждый из которых проверяет одну из функций ресурса. Каждый оператор описывает ожидаемое состояние системы как утверждение. Также вы можете включить два ключевых слова, should и should_not – они утверждают, что условие должно быть истинным и ложным соответственно.

Создайте файл os_family.rb для вашего теста:

nano os_family.rb

Добавьте в файл:

describe os.family do it {should eq 'debian'} end

Этот тест убедится в том, что целевая система относится к семейству debian. Другими возможными значениями являются windows, unix, bsd и т. д. Вы можете найти полный список в документации по ресурсу os. Сохраните файл и закройте его.

Затем запустите тест с помощью следующей команды:

inspec exec os_family.rb

Когда тест будет выполнен, вы получите примерно такой вывод:

Profile: tests from os_family.rb (tests from os_family.rb) Version: (not specified) Target: local:// debian ✔ should eq "debian" Test Summary: 1 successful, 0 failures, 0 skipped

В выходных данных Profile указывает имя только что выполненного профиля. Поскольку этот тест не включен в профиль, InSpec генерирует имя профиля по умолчанию, добавляя «tests from» к названию файла (os_family.rb). Мы будем работать с профилями InSpec в следующем разделе. Здесь InSpec представляет Version как not specified, поскольку версии можно указывать только в профилях.

Поле Target указывает целевую систему, в которой выполняется тест, она может быть локальной или удаленной по ssh. В этом случае тест был выполнен в локальной системе, поэтому Target указывает local://.

Выходные данные также отмечают выполненный тест символом галочки (✔) слева – это значит, что тест выполнен успешно. Если тест не пройден, в выводе будет крестик (✘).

Краткий отчет о тестах (Test Summary) дает общую информацию о том, сколько тестов выполнено успешно, сколько провалено и пропущено. В этом случае был всего один тест, и он прошел успешно.

Теперь давайте посмотрим, как выглядит результат неудавшегося теста. Откройте os_family.rb:

nano os_family.rb

В тесте, который вы создали ранее, измените значение семейства с debian на windows. Содержимое файла после этого будет таким:

describe os.family do it {should eq 'windows'} end

Затем запустите обновленный тест с помощью следующей команды:

inspec exec os_family.rb

Вы получите такой результат:

Profile: tests from os_family.fail.rb (tests from os_family.fail.rb) Version: (not specified) Target: local:// debian (✘) should eq "windows" expected: "windows" got: "debian" (compared using ==) Test Summary: 0 successful, 1 failure, 0 skipped

Как и ожидалось, тест провалился. Вывод показывает, что ваши ожидаемые (windows) и фактические (debian) значения для свойства os.family не совпадают. Строка (compared using ==) указывает, что сопоставитель eq сравнил два значения, чтобы получить этот результат.

Итак, вы написали первый простой тест, который проверяет семейство операционной системы сервера. Вы также знаете, как выглядит неудавшийся тест в выводе InSpec.

3: Аудит установки PostgreSQL

Теперь можно проверить вашу установку PostgreSQL. Для начала нужно убедиться, что экземпляр PostgreSQL установлен и его сервис работает правильно. Затем нужно проверить порт и процесс PostgreSQL. Для аудита PostgreSQL нужно создать различные элементы InSpec, все они будут в профиле InSpec по имени PostgreSQL.

Элемент управления InSpec – это высокоуровневая группа связанных тестов. Внутри элемента управления вы можете определить несколько блоков describe, а также метаданные для описания ваших тестов (такие как уровень воздействия, заголовок, описание и теги). Профили InSpec организуют элементы воедино для простоты управления зависимостями и повторного использования кода. Они также полезны для упаковки и обмена тестами с другими разработчиками через Chef Supermarket. Вы можете использовать профили для определения пользовательских ресурсов, которые вы будете реализовывать как обычные классы Ruby.

Чтобы создать профиль InSpec, используйте команду init. Чтобы создать профиль PostgreSQL, введите:

inspec init profile PostgreSQL

Она создаст в новом каталоге профиль (в данном случае он называется PostgreSQL). Теперь перейдите в новый каталог:

cd PostgreSQL/

Структура каталогов будет выглядеть так:

PostgreSQL/ ├── controls │ └── example.rb ├── inspec.yml ├── libraries └── README.md

Файл controls/example.rb содержит пример элемента управления, который проверяет, существует ли в целевой системе папка /tmp. Этот профиль присутствует только в качестве образца, и вы можете заменить его своим собственным тестом.

Первый тест будет проверять, установлен ли в вашей системе пакет postgresql-10 и как работает сервис postgresql.

Переименуйте controls/example.rb в controls/postgresql.rb.

mv controls/example.rb controls/postgresql.rb

Затем откройте файл в редакторе:

nano controls/postgresql.rb

Замените его содержимое таким кодом:

control '1-audit_installation' do impact 1.0 title 'Audit PostgreSQL Installation' desc 'Postgres should be installed and running' describe package('postgresql-10') do it {should be_installed} its('version') {should cmp >= '10'} end describe service('postgresql@10-main') do it {should be_enabled} it {should be_installed} it {should be_running} end end

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

В первом блоке describe ресурс package передает в качестве аргумента ресурса имя пакета postgresql-10. Ресурс package предоставляет сопоставитель be_installed, который подтверждает, что указанный пакет установлен в системе. Он возвращает true, если пакет установлен, в противном случае он вернет false. Затем идет оператор it, который подтверждает, что версия установленного пакета PostgreSQL не меньше 10. Здесь используется cmp вместо eq, потому что строки версии пакета обычно содержат другие атрибуты (помимо числовой версии). eq возвращает true, только если находит точное совпадение, а cmp менее ограничителен.

Во втором блоке describe используется ресурс service, а в качестве аргумента ресурса передается имя сервиса postgresql@10-main. Ресурс service предоставляет средства сопоставления be_enabled, be_installed и be_running. Они возвращают значение true, если указанный сервис установлен, включен и работает в целевой системе.

Сохраните и закройте файл.

Запустите свой профиль. Убедитесь, что вы находитесь в каталоге ~/PostgreSQL, прежде чем выполнять следующую команду:

inspec exec .

Если вы выполнили требования этого мануала и заранее установили PostgreSQL, тест будет пройден успешно. Вывод будет выглядеть примерно так:

Элемент управления считается успешным, только если все тесты в нем выполнены успешно. Согласно выводу, так и есть – все тесты прошли успешно.

Теперь, когда вы убедились, что в системе установлена правильная версия PostgreSQL и сервис работает правильно, можно создать новый элемент управления, который проверяет правильность порта, адреса и протокола PostgreSQL.

Для этого теста нужно использовать атрибуты. Атрибут InSpec используется для параметризации профиля, что обеспечивает легкое повторное использование в различных средах или целевых системах. Здесь мы используем атрибут PORT.

Откройте файл inspec.yml в текстовом редакторе:

nano inspec.yml

Добавьте атрибут port в конец файла:

... attributes: - name: port type: string default: '5432'

В предыдущем блоке кода вы указали атрибут port и установили для него стандартное значение 5432 (потому что это порт, который PostgreSQL прослушивает по умолчанию).

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

inspec check .

Если ошибок нет, можете продолжить. В противном случае откройте файл inspec.yml и убедитесь, что атрибут находится в конце файла.

Теперь нужно создать элемент управления, который подтверждает, что процесс PostgreSQL запущен и поддерживается правильным пользователем. Откройте файл controls/postgresql.rb в текстовом редакторе:

nano controls/postgresql.rb

В конец текущей настройки добавьте следующие строки:

... PORT = attribute('port') control '2-audit_address_port' do impact 1.0 title 'Audit Process and Port' desc 'Postgres port should be listening and the process should be running' describe port(PORT) do it {should be_listening} its('addresses') {should include '127.0.0.1'} its('protocols') {should cmp 'tcp'} end describe processes('postgres') do it {should exist} its('users') {should include 'postgres'} end describe user('postgres') do it {should exist} end end

Переменная PORT хранит значение атрибута port. Затем идут элемент управления и его метаданные.

В первом блоке describe включен ресурс port, который нужен для проверки основных свойств порта. Ресурс port предоставляет сопоставители be_listening, addresses, and protocols. Сопоставитель be_listening проверяет, прослушивается ли указанный порт в целевой системе. Он возвращает true, если порт 5432 прослушивается, в противном случае возвращает false. Сопоставитель addresses проверяет, связан ли указанный адрес с портом. В этом случае PostgreSQL будет прослушивать локальный адрес 127.0.0.1.

Сопоставитель protocols проверяет интернет-протокол, который прослушивает порт (icmp, tcp/tcp6 или udp/udp6). PostgreSQL будет прослушивать TCP-соединения.

Во втором блоке describe находится ресурс processes. Ресурс processes используется для проверки свойств программ, работающих в системе. Сначала он проверяет, существует ли процесс postgres в системе. Затем используется сопоставитель users, который подтверждает, что пользователь postgres управляет процессом postgres.

В третьем блоке describe находится ресурс user. Он нужен для проверки свойств пользователя: существует ли этот пользователь или нет, к какой группе он принадлежит и т. д. Этот ресурс позволяет проверить, существует ли в системе пользователь postgres. Сохраните и закройте postgresql.rb.

Запустите этот профиль:

inspec exec .

Когда тесты будут выполнены, вы увидите вывод:

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

Только что вы создали свой первый профиль и элемент управления InSpec и использовали их для систематизации своих тестов. В них вы использовали несколько ресурсов InSpec.

4: Анализ конфигурации PostgreSQL

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

Теперь, когда у вас есть тесты для проверки установки экземпляра PostgreSQL, вы можете проверить свою конфигурацию PostgreSQL. PostgreSQL имеет несколько параметров конфигурации, которые вы можете использовать для настройки по своему желанию. Они хранятся в конфигурационном файле, расположенном по умолчанию в /etc/postgresql/10/main/postgresql.conf. У различных развертываний могут быть разные требования к конфигурации PostgreSQL (например, логирование, шифрование пароля, SSL и стратегии репликации) – эти требования вы указываете в конфигурационном файле.

Вы можете использовать ресурс postgres_conf, который проверяет конкретные именованные параметры конфигурации на соответствие ожидаемым значениям.

Этот тест будет учитывать некоторые нестандартные значения конфигурации PostgreSQL, которые вы установите вручную.

Откройте конфигурационный файл PostgreSQL в текстовом редакторе:

sudo nano /etc/postgresql/10/main/postgresql.conf

Установите следующие значения конфигурации. Если опция уже существует в файле, но закомментирована, раскомментируйте ее, удалив символ #, и установите следующие значения:

password_encryption = scram-sha-256 logging_collector = on log_connections = on log_disconnections = on log_duration = on

Вы установили значения конфигурации, которые делают следующее:

Гарантируют шифрование сохраненных паролей с помощью алгоритма scram-sha-256.
Включают logging collector – это фоновый процесс, который захватывает сообщения журнала из стандартной ошибки (stderr) и перенаправляет их в лог-файл.
Включают регистрацию попыток подключения к серверу PostgreSQL, а также случаи успешных подключений.
Включают логирование завершения сеанса.
Включают логирование продолжительности каждого выполненного оператора.

Сохраните и закройте конфигурационный файл. Затем перезапустите сервис PostgreSQL:

sudo service postgresql@10-main restart

Сейчас вы протестируете только несколько параметров конфигурации, но позже вы можете протестировать больше параметров PostgreSQL с помощью ресурса postgres_conf.

Определите каталог конфигурации PostgreSQL, /etc/postgresql/10/main, используя новый атрибут профиля, postgres_conf_dir. Этот каталог конфигурации не всегда совпадает во всех операционных системах и платформах, поэтому, передав его в качестве атрибута, вы упростите его повторное использование в различных средах.

Откройте файл:

nano inspec.yml

Добавьте новый атрибут в раздел attributes:

... - name: postgres_conf_dir type: string default: '/etc/postgresql/10/main'

Сохраните и закройте файл. Запустите следующую команду, чтобы убедиться, что профиль InSpec все еще валиден после редактирования inspec.yml.

inspec check .

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

Теперь нужно создать элемент управления, который проверяет указанные значения конфигурации. Добавьте следующий элемент управления в конец файла controls/postgresql.rb:

... POSTGRES_CONF_DIR = attribute('postgres_conf_dir') POSTGRES_CONF_PATH = File.join(POSTGRES_CONF_DIR, 'postgresql.conf') control '3-postgresql' do impact 1.0 title 'Audit PostgreSQL Configuration' desc 'Audits specific configuration options' describe postgres_conf(POSTGRES_CONF_PATH) do its('port') {should eq PORT} its('password_encryption') {should eq 'scram-sha-256'} its('ssl') {should eq 'on'} its('logging_collector') {should eq 'on'} its('log_connections') {should eq 'on'} its('log_disconnections') {should eq 'on'} its('log_duration') {should eq 'on'} end end

Здесь определены две переменные:

POSTGRES_CONF_DIR содержит атрибут postgres_conf_dir, как определено в конфигурации профиля.
POSTGRES_CONF_PATH содержит абсолютный путь к конфигурационному файлу и каталогу с помощью File.join.

Далее вы определяете элемент, его имя и метаданные. Затем вы используете ресурс postgres_conf вместе с сопоставителем eq, чтобы убедиться, что требуемые значения конфигурации соблюдаются. Сохраните и закройте файл postgresql.rb.

Запустите тест с помощью следующей команды:

inspec exec .

Когда все тесты будут выполнены, вы получите такой вывод:

Profile: InSpec Profile (PostgreSQL) Version: 0.1.0 Target: local:// ✔ 1-audit_installation: Audit PostgreSQL Installation ✔ System Package postgresql-10 should be installed ✔ System Package postgresql-10 version should cmp >= "10" ✔ Service postgresql@10-main should be enabled ✔ Service postgresql@10-main should be installed ✔ Service postgresql@10-main should be running ✔ 2-audit_address_port: Audit Process and Port ✔ Port 5432 should be listening ✔ Port 5432 addresses should include "127.0.0.1" ✔ Port 5432 protocols should cmp == "tcp" ✔ Processes postgres should exist ✔ Processes postgres users should include "postgres" ✔ User postgres should exist ✔ 3-postgresql: Audit PostgreSQL Configuration ✔ PostgreSQL Configuration port should eq "5432" ✔ PostgreSQL Configuration password_encryption should eq "scram-sha-256" ✔ PostgreSQL Configuration ssl should eq "on" ✔ PostgreSQL Configuration logging_collector should eq "on" ✔ PostgreSQL Configuration log_connections should eq "on" ✔ PostgreSQL Configuration log_disconnections should eq "on" ✔ PostgreSQL Configuration log_duration should eq "on" Profile Summary: 3 successful controls, 0 control failures, 0 controls skipped Test Summary: 18 successful, 0 failures, 0 skipped

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

Теперь попробуйте самостоятельно использовать профиль для проверки других параметров из конфигурационного файла.

5: Анализ клиентской аутентификации PostgreSQL

Теперь, когда вы написали несколько тестов для конфигурации PostgreSQL, можно попробовать составить несколько тестов для аутентификации клиента. Это важно для тех установок, которые должны обеспечить определенные методы аутентификации для разных типов пользователей (например, чтобы клиенты, подключающиеся к PostgreSQL локально, могли авторизоваться с помощью пароля, или чтобы отклонить подключения с определенного IP-адреса или диапазона IP-адресов и т. д.).

Если для вашего экземпляра PostgreSQL важна безопасность, аутентификация должна происходить только по зашифрованным паролям. PostgreSQL 10 поддерживает два метода шифрования пароля для аутентификации клиента: md5 и scram-sha-256. Этот тест потребует шифрования пароля для всех клиентов. Это означает, что в поле METHOD в конфигурации клиента должно быть задано либо md5, либо scram-sha-256 (для всех клиентов). Здесь мы используем метод scram-sha-256, поскольку он более безопасен, чем md5.

По умолчанию клиенты local имеют свой метод одноранговой аутентификации (peer) в файле pg_hba.conf. Чтобы тест прошел удачно, вам нужно изменить это значение на scram-sha-256. Откройте файл /etc/postgresql/10/main/pg_hba.conf:

sudo nano /etc/postgresql/10/main/pg_hba.conf

Верхняя часть файла содержит комментарии. Прокрутите вниз и найдите раскомментированные строки, где тип аутентификации – local, и измените метод аутентификации с peer на scram-sha-256. Например, это:

... local all postgres peer ...

нужно изменить так:

... local all postgres scram-sha-256 ...

В конце файл pg_hba.conf будет выглядеть следующим образом:

... local all postgres scram-sha-256 # TYPE DATABASE USER ADDRESS METHOD # "local" is for Unix domain socket connections only local all all scram-sha-256 # IPv4 local connections: host all all 127.0.0.1/32 scram-sha-256 # IPv6 local connections: host all all ::1/128 scram-sha-256 # Allow replication connections from localhost, by a user with the # replication privilege. local replication all scram-sha-256 host replication all 127.0.0.1/32 scram-sha-256 host replication all ::1/128 scram-sha-256 ...

Сохраните и закройте файл. Перезапустите сервис:

sudo service postgresql@10-main restart

В этом тесте нужно использовать ресурс postgres_hba_conf. Этот ресурс применяется для проверки данных аутентификации клиента, определенных в файле pg_hba.conf. Передайте путь к файлу pg_hba.conf в качестве параметра этого ресурса.

Элемент управления будет состоять из двух блоков describe, которые проверяют поля auth_method для клиентов local и host соответственно, чтобы убедиться, что они оба содержат scram-sha-256. Откройте файл controls/postgresql.rb в текстовом редакторе:

nano controls/postgresql.rb

Вставьте в конец файла следующий элемент:

POSTGRES_HBA_CONF_FILE = File.join(POSTGRES_CONF_DIR, 'pg_hba.conf') control '4-postgres_hba' do impact 1.0 title 'Require SCRAM-SHA-256 for ALL users, peers in pg_hba.conf' desc 'Require SCRAM-SHA-256 for ALL users, peers in pg_hba.conf. Do not allow untrusted authentication methods.' describe postgres_hba_conf(POSTGRES_HBA_CONF_FILE).where { type == 'local' } do its('auth_method') { should all eq 'scram-sha-256' } end describe postgres_hba_conf(POSTGRES_HBA_CONF_FILE).where { type == 'host' } do its('auth_method') { should all eq 'scram-sha-256' } end end

В этом блоке кода определяется новая переменная POSTGRES_HBA_CONF_FILE, она нужна для хранения абсолютного местоположения вашего файла pg_hba.conf. File.join – это метод Ruby для объединения двух сегментов пути к файлу с помощью слеша. Здесь он используется для соединения переменной POSTGRES_CONF_DIR, объявленной в предыдущем разделе, с файлом pg_hba.conf. Это создаст абсолютный путь к файлу pg_hba.conf и сохранит его в переменной POSTGRES_HBA_CONF_FILE.

После этого идет объявление и настройка элемента управления и его метаданные. Первый блок describe подтверждает, что все записи, где тип клиента – local, используют метод аутентификации scram-sha-256. Второй блок describe делает то же самое для клиентов, которые относятся к типу host. Сохраните и закройте controls/postgresql.rb.

Запустите этот элемент управления как пользователь postgres, поскольку доступ на чтение конфигурации HBA PostgreSQL предоставляется только владельцу и группе (в данном случае все права принадлежат пользователю postgres). Запустите команду:

sudo -u postgres inspec exec .

Вы получите такой вывод:

Profile: InSpec Profile (PostgreSQL) Version: 0.1.0 Target: local:// ✔ 1-audit_installation: Audit PostgreSQL Installation ✔ System Package postgresql-10 should be installed ✔ System Package postgresql-10 version should cmp >= "10" ✔ Service postgresql@10-main should be enabled ✔ Service postgresql@10-main should be installed ✔ Service postgresql@10-main should be running ✔ 2-audit_address_port: Audit Process and Port ✔ Port 5432 should be listening ✔ Port 5432 addresses should include "127.0.0.1" ✔ Port 5432 protocols should cmp == "tcp" ✔ Processes postgres should exist ✔ Processes postgres users should include "postgres" ✔ User postgres should exist ✔ 3-postgresql: Audit PostgreSQL Configuration ✔ PostgreSQL Configuration port should eq "5432" ✔ PostgreSQL Configuration password_encryption should eq "scram-sha-256" ✔ PostgreSQL Configuration ssl should eq "on" ✔ PostgreSQL Configuration logging_collector should eq "on" ✔ PostgreSQL Configuration log_connections should eq "on" ✔ PostgreSQL Configuration log_disconnections should eq "on" ✔ PostgreSQL Configuration log_duration should eq "on" ✔ 4-postgres_hba: Require SCRAM-SHA-256 for ALL users, peers in pg_hba.conf ✔ Postgres Hba Config /etc/postgresql/10/main/pg_hba.conf with type == "local" auth_method should all eq "scram-sha-256" ✔ Postgres Hba Config /etc/postgresql/10/main/pg_hba.conf with type == "host" auth_method should all eq "scram-sha-256" Profile Summary: 4 successful controls, 0 control failures, 0 controls skipped Test Summary: 20 successful, 0 failures, 0 skipped

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

Заключение

Вы настроили InSpec и успешно провели анализ установки PostgreSQL 10. В процессе вы научились использовать набор инструментов InSpec: InSpec DSL, сопоставители, ресурсы, профили, атрибуты и CLI. Теперь вы можете включить в свои тесты другие ресурсы, которые предоставляет InSpec (см. этот раздел документации). InSpec также предоставляет механизм для определения пользовательских ресурсов. Эти пользовательские ресурсы пишутся как обычные классы Ruby.

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

Вы можете исследовать другие инструменты Chef, например Chef и Habitat. InSpec интегрирован с Habitat, и это дает возможность загружать ваши данные вместе с пакетированными приложениями Habitat и непрерывно их запускать. Здесь можно найти много официальных мануалов и руководства, написанные сообществом. Также читайте официальную документацию InSpec.

Tags: InSpec, PostgreSQL, Ubuntu 18.04

Добавить комментарий Отменить ответ

Для отправки комментария вам необходимо авторизоваться.