Глава 2. Защита ваших ключей безопасности в Ansible

Ознакомьтесь с видеоматериалами Code in Action.

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

Однако, это создаёт некий риск! Ваша секретная информация располагается где- то в вашей файловой системе в обычном тексте. Именно это является риском физически и цифровым образом. Физически можно изъять у вас этот компьютер и залапать секретные данные. При цифровым способе любое вредоносное программное обеспечение, которое прорвёт ограждение сможет считать любые данные учётных записей ваших пользователей для получения доступа. Если вы применяете некую систему контроля исходного кода, вся инфраструктура, которая размещает это репозиторий, также находится в зоне большого риска.

К счастью, Ansible предоставляет некие средства для защиты ваших данных в их состоянии покоя. Этим средством является Vault (склеп). Данное средство позволяет шифровать текстовые файлы с тем, чтобы они хранились в состоянии покоя в некотором закрытом формате. Без наличия определённого ключа или значительной вычислительной мощности эти данные не поддаются расшифровке.

Ключевыми уроками для изучения при работе с зашифрованными данными в состоянии покоя являются:

Вплоть до выпуска Ansible 2.4 имелась возможность применения в определённый момент лишь одного пароля Vault. Хотя вы могли бы иметь множество секретов для большого числа целей, которые хранились бы в некотором числе местоположений, мог применяться лишь один пароль. Очевидно что это прекрасно в небольших средах, но так как принятие Ansible расло, появилось требование для лучших и более гибких вариантов безопасности. Например, мы уже обсуждали потенциал Ansible управления как средой разработки, так и промышленной реализацией посредством применения групп в соответствующей описи (inventory). Будет правильным ожидать что такие среды будут иметь различные параметры доступа безопасности. Аналогично, вы бы ожидали чтобы сетевые устройства ядра имели бы различные параметры доступа к серверам. Это и взаправду хорошая практика поступать именно так.

Принимая это, кажется не обоснованным после этого защищать все секреты под отдельным паролем хозяина при помощи Vault. Ansible 2.4 в качестве решения ввёл понятие идентификаторов Vault и в то время как на текущий момент всё ещё допустимы старые команды отдельным паролем, рекомендуется применять при работе с командной строкой идентификаторы Vault. Всякий идентификатор Vault обязан иметь отдельный связанный с ним пароль, однако множество секретов могут совместно применять один и тот же идентификатор.

Пароли Ansible Vault могут поступать в виде одного из трёх источников:

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

ansible-playbook --vault-id @prompt playbook.yaml
		

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

ansible-playbook --vault-id /path-to/vault-password-text-file playbook.yaml
		

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

ansible-playbook --vault-id /path-to/vault-password-script.py playbook.yaml
		

Когда вы работаете с идентификаторами, просто добавляйте значение идентификатора перед самим источником пароля, за которым следует символ @ - скажем, когда вашим идентификатором является prod, три наших предыдущих примера становятся такими:

ansible-playbook --vault-id prod@prompt playbook.yaml
ansible-playbook --vault-id prod@/path-to/vault-password-text-file playbook.yaml
ansible-playbook --vault-id prod@/path-to/vault-password-script.py playbook.yaml
		

Множество таких сочетаний можно собрать в одну команду таким образом:

ansible-playbook --vault-id prod@prompt testing@/path-to/vault-password text-file playbook.yaml
		

На протяжении оставшейся части этой главы мы будем применять параметры командной строки vault-id.

Само средство Vault может применяться для шифрования любых файлов с структурированными данными, применяемыми Ansible. Это по существу любой файл YAML (или JSON), который Ansible применяет в процессе своей работы, либо даже отдельная переменная внутри в противном случае незашифрованного файла YAML, такого как некий плейбук или какая- то роль. примерами зашифрованных файлов, с которыми способен работать Ansible, могут включать в себя:

Если такой файл может быть выражен в YAML и считан Ansible, или если этот файл должен быть передан модулем copy, это точно некий файл для шифрования его с помощью Vault. Поскольку весь файл целиком будет не читаемым в состоянии покоя, следует позаботиться о том, чтобы не переусердствовать с выбором подлежащих шифрованию файлов. Все операции управления версиями будут выполняться с зашифрованным содержимым, что очень сильно затруднит экспертизу.

В качестве наилучшего практического опыта следует шифровать как можно меньшее количество возможных данных, что может даже означать перемещение некоторых переменных в отдельный самостоятельный файл. Именно по этой причине в Ansible 2.3 было добавлено свойство encrypt_string для ansible-vault, что сделало возможным помещение индивидуальных секретов вовнутрь прочего не зашифрованного YAML, избавляя пользователя от потребности шифрования всего файла целиком. Позднее в этой главе мы обсудим это.

Для создания новых файлов Ansible предоставляет некую новую программу, ansible-vault. Эта программа применяется для создания и взаимодействия с шифрованными Vault файлами. Той процедурой, которая создаёт шифрованные файлы, является процедура create, как это показано на следующем снимке экрана:

Чтобы создать некий новый файл, вам необходимо знать наперёд два момента. Самым первым является тот пароль, который ansible-vault будет применять для шифрования этого файла, а вторым выступает название самого файла. Когда эта информация предоставлена, ansible-vault запустит некий текстовый редактор (который определён в вашей переменной среды EDITOR). Когда вы сохраните этот файл и выйдите из данного редактора, ansible-vault воспользуется предоставленным паролем в качестве ключа для шифрования данного файла шифром AES256.

Давайте пройдём несколько примеров создания зашифрованных файлов. Вначале мы создадим один и получим приглашение на ввод некого пароля, затем мы предоставим какой- то файл password, а напоследок мы создадим исполняемый для доставки своего пароля.

Приглашение ко вводу пароля

Заставить ansible-vault выдавать запрос на некий пароль данного пользователя при работе это самый простой способ для начала создания Vault, поэтому давайте проследуем неким простым примером и создадим некий Vault, содержащий какую- то переменную, которую мы желаем зашифровать. Взгляните на следующий снимок экрана:

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

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

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

Файл пароля

Чтобы воспользоваться ansible-vault с неким файлом password, нам вначале нужно создать такой файл. {Это можно сделать простым выводом echo некоего пароля в какой- то файл.} Когда это сделано, мы можем сослаться на этот файл при вызове ansible-vault для создания другого зашифрованного файла, как это показано на приводимом ниже снимке экрана:

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

Сценарий пароля

Этот последний пример использует некий сценарий пароля. Он полезен при проектировании некоторой системы, в которой какой- то пароль может быть сохранён в некоторой центральной системе для хранения удостоверений и совместно применяться для сослуживцев по данному дереву плейбука. Каждый сослуживец может иметь его или её собственный пароль для совместного использования хранилища удостоверений и из которой будет выбираться определённый пароль Vault. Наш пример будет намного проще: всего лишь простейший вывод в стандартный выход с некоторым паролем. Такой файл будет сохранён как password.sh. Этот файл нужно пометить как некий исполняемый для Ansible, чтобы воспринимать его таковым, как это следует из снимка экрана внизу:

Попробуйте это самостоятельно и вы увидите как это работает - вы должны обнаружить, что ansible-vault создаёт некий Vault с паролем a long password, который выводится в STDOUT данным сценарием. Вы можете даже попытаться изменить его при помощи следующей команды:

ansible-vault edit --vault-id @prompt even_more_secrets.yaml
		

Теперь вы можете видеть введённым a long password при запросе приглашения и сейчас вы можете успешно изменять данный Vault!

Все предыдущие примеры имели дело с созданием новых шифрованных файлов с применением определённой подкоманды create. Но что если мы желаем взять некий установленный файл и зашифровать его? Для этого также имеется некая подкоманда. Она именуется как encrypt, что вы можете видеть на следующем снимке экрана:

Как и в случае с create, encrypt ожидает некий password (или файл password, или нечто исполняемое) и определённый путь к какому- то файлу. Когда соответствующий пароль выбран, откроется редактор, причём на этот раз с нашим первоначальным содержимым в простом текстовом виде, уже доступном для нас.

Давайте продемонстрируем это зашифровав некий существующий файл, который мы имеем из предыдущей Главы 1, Архитектура системы и проектирование Ansible, с названием a_vars_file.yaml, как это показано далее на снимке экрана:

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

После того как некий файл был зашифрован с помощью ansible-vault, он не может изменяться напрямую. Открытие этого файла в некотором редакторе имело бы результатом отображение неких зашифрованных данных. Выполнение любых изменений в таком файле разрушит этот файл и Ansible будет не в состоянии считывать его содержимое правильно. Нам требуется некая процедура, которая вначале расшифрует всё содержимое этого файла, позволяя нам изменять его содержимое, а затем зашифрует полученное новое содержимое, прежде чем сохранит его обратно в этот файл. Такая процедура имеется и она называется edit, как это демонстрирует следующий снимок экрана:

Как мы уже наблюдали, откроется наш редактор с нашим содержимым в обычном текстовом виде, видимом нами. Все знакомые нам варианты vault-id вернулись вновь как и ранее, также как когда мы изменяли данный файл. Раз так, мы теперь можем вносить в этот файл изменения в только что зашифрованный файл при помощи такой команды:

Отметим, что ansible-vault откроет наш редактор с каим- то временным файлом в качестве значения пути файла. Этот редактор сохранит его, а затем ansible-vault зашифрует его и переместит его для замены первоначального файла, как это показано на снимке экрана далее:

Тот временный файл, который вы могли наблюдать в самом окне редактора (/tmp/tmpVvcJBK.yaml) будет удалён после успешной операции шифрования со стороны ansible-vault.

Со временем, когда сослуживцы приходят и уходят, будет неплохо чередовать те пароли, которые применяются для шифрования вашей секретной информации. Шифрование хорошо только тогда, когда защищено надлежащим паролем. ansible-vault предоставляет некую подкоманду, которая позволяет нам изменять текущий пароль и носит название rekey, как это показано на снимке экрана далее:

Данная подкоманда rekey работает как подкоманда edit. Она получает некий необязательный пароль, файл или нечто исполняемое, а также один или более файлов для rekey. Затем вы применяете --new-vault-id для задания значения нового пароля (а также если требуется, то и идентификатора), что опять- таки может быть сделано через приглашение, файл или нечто исполняемое. Давайте выполним rekey своего файла even_more_secrets.yaml в нашем следующем примере и добавим к нему идентификатор dev:

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

Если в некоторый момент потребность шифровать файлы исчезла, ansible-vault предоставляет некую подкоманду, которую можно применить для удаления шифрования для одного или более зашифрованных файлов. Эта подкоманда именуется как decrypt и показана на следующем снимке экрана:

Опять же, мы должны применить некий знакомые нам параметры --vault-id с последующими одним или более путями файлов для дешифрации. Давайте выполним дешифрацию того файла, который мы создали ранее при помощи своего файла password, как это показано на предоставленном далее снимке экрана:

В нашем следующем разделе мы увидим как исполнять плейбук Ansible с зашифрованными файлами.

Чтобы применять наше зашифрованное содержимое, нам необходимо иметь возможность уведомить ansible-playbook как получить доступ к любым зашифрованным данным, с которыми он может столкнуться. В отличии от ansible-vault, который существует исключительно для того, чтобы иметь дело с шифрованием или дешифрацией, ansible-playbook является более многоплановым и он не будет предполагать, что он имеет дело с зашифрованными данными по умолчанию. К счастью, все параметры ansible-vault с которыми мы ознакомились в своих предыдущих примерах работатю точно так же в ansible-playbook, как это было в случае с ansible-vault. Ansible удерживает все предоставленные ему пароли и идентификаторы в оперативной памяти на протяжении исполнения данного плейбука.

Давайте теперь создадим некий простой плейбук с названием show_me.yaml, который выведет на печать имеющееся внутри значение своей переменной a_vars_file.yaml, которую мы зашифровали в предыдущем примере, следующим образом:

-- 
- name: show me an encrypted var 
  hosts: localhost 
  gather_facts: false 
 
  vars_files: 
    - a_vars_file.yaml 
 
  tasks: 
    - name: print the variable 
      debug: 
        var: something
 	   

Теперь давайте запустим этот плейбук и посмотрим что произойдёт. Отметим, что мы теперь применяем параметр --vault-id в точности так же как мы поступали с ansible-vault; между этими двумя исполняемыми файлами поддерживается целостность чтобы вы имели возможность применить всё что вы изучали ранее в этой главе относительно применения --vault-id. Взглянем на такой снимок экрана:

Как вы можете видеть, наш плейбук исполнился успешно и вывел на печать незашифрованное значение данной переменной, даже несмотря на то, что тот исходный файл переменной, который мы вложили, являлся неким Ansible Vault. Естественно, вам не следует выводить некое секретное значение на свой Теминал при реальном исполнении плейбука, но это демонстрирует насколько просто получать доступ к данным в Vault.

До выпуска Ansible 2.3 секретные данные приходилось шифровать в неком отдельном файле. По обозначенным ранее причинам было желательным шифровать по возможности меньше данных. Теперь это возможно (а также избавляет от потребности в слишком большом числе файлов как части некого плейбука) через применение подкоманды encrypt_string для ansible-vault, которая производит некую зашифрованную строку, которую можно помещать в файле YAML Ansible. Давайте начнём со следующего базового плейбука в качестве примера:

--
- name: inline secret variable demonstration
  hosts: localhost
  gather_facts: false

  vars:
    my_secret: secure_password

  tasks:
    - name: print the secure variable
      debug:
        var: my_secret
 	   

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

Теперь, очевидно, не будет умно оставлять некий пароль секрета в простом текстовом файле как тут. Поэтому вместо того чтобы оставлять его таковым, давайте зашифруем его при помощи подкоманды encrypt_string из ansible-vault таким образом:

Итак, если мы желаем создать некий зашифрованный блок текста для своей переменной с названием my_secret с зашифрованной строкой secure_password при помощи своего проверочного идентификатора Vault и имеющегося сценария password.sh, который мы создали ранее для своего пароля, нам надо выполнить следующее:

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

Однако когда мы запускаем предыдущее с предоставлением надлежащего --vault-id, к данной информации можно осуществлять доступ как и ко всем прочим данным Vault, что показано на снимке экрана далее:

Обратите внимание, что этот плейбук исполняется в точности так же, как мы это наблюдали при самом первом его тестировании, когда все данные были открыты на обозрение всего честного мира. Теперь, однако, у нас имеется смесь наших зашифрованных данных с прочими не шифрованными в плейбуке YAML. Далее мы погрузимся глубже в некие стороны работы исполняемых совместно с Ansible Vault плейбуков.

В своём предыдущем разделе этой главы мы обсудили защиту вашей секретной информации в состоянии покоя в определённой файловой системе. Однако, это не относится к варианту, когда Ansible работает с секретными данными. Такие секретные данные могут использоваться в задачах в виде аргументов модуля или в циклах ввода, либо в целом ряде прочих вещей. Это может вызвать передачу данных на удалённые хосты, протоколироваться в локальные или удалённые файлы регистрации, или отображаться на экране. Данный раздел текущей главы обсудит стратегии для защиты ваших секретных данных во время работы.

Как мы уже изучали в Главе 1, Архитектура системы и проектирование Ansible, Ansible будет комбинировать код и аргументы модуля и записывать это в некий временный каталог на своём удалённом хосте. Это означает, что ваши секретные данные передаются по кабелю И записываются в вашу удалённую файловую систему. Пока вы не применяете некий подключаемый модуль соединения, отличающийся от шифруемых SSH, SSL или winrm, все передаваемые по вашему кабелю данные уже шифруются, предоставляя безопасность вашей секретной информации от её исследования простыми средствами перехвата {Прим. пер.: см., например, Python Scapy}. Если вы применяете некий отличающийся от SSH подключаемый модуль соединения, ознакомьтесь с тем шифруются или нет ваши данные при их передаче. Применение любого метода соединения без шифрования является крайне не оптимистичным.

Когда ваши данные переданы, Ansible может записать эти данные открытым способом в имеющуюся файловую систему. Это может произойти если не применяется pipelining (который мы изучали в Главе 1, Архитектура системы и проектирование Ansible), ИЛИ если Ansible получил указание через имеющуюся переменную среды ANSIBLE_KEEP_REMOTE_FILES оставлять удалённые файлы на месте. Без организации конвейеров Ansible запишет сам модуль, код плюс аргументы, в некий временный каталог, который должен быть обнаружен в процессе исполнения. Если произойдёт потеря связи между записывающей этот файл стороной и исполняющей его стороной, такой файл останется в имеющейся удалённой файловой системе пока не будет удалён вручную. Если Ansible в явном виде получил указание оставлять удалённые файлы на своём месте, тогда, даже если конвейеризация включена, Ansible запишет и оставит удалённые файлы на месте. С такими вариантами надо быть настороже относительно высокочувствительной секретной информации, даже несмотря на то, что обычно только сам зарегистрированный (или становится таким посредством эскалации полномочий) на данном удалённом хосте пользователь Ansible должен иметь доступ к такому оставшемуся файлу. Простое удаление всего в вашем пути ~/.ansible/tmp/ для имеющегося удалённого пользователя будет достаточным для очистки секретной информации.

Когда Ansible работает с неким хостом, он попытается регистрировать все действия в syslog (если применяется третий уровень многословности пояснений). Если эти действия осуществляются неким пользователем с соответствующими правами, это вызовет появление неких сообщений в имеющемся файле syslog на таком хосте. Эти сообщения содержат само название модуля и все аргументы, передаваемые совместно с такой командой, которые могут содержать вашу секретную информацию. Чтобы предотвратить такое происшествие, имеется некий ключ воспроизведения и задачи с названием no_log. Установка no_log в значение true предотвратит Ansible от протоколирования своих действий в syslog.

Локально Ansible также может получать указания выполнять протоколирование своих действий. Это управляется либо через log_path в файле config Ansible, либо через некую переменную среды c названиеv ANSIBLE_LOG_PATH. По умолчанию регистрация отключена и Ansible будет выполнять протоколирование в STDOUT. Переключение регистрации во включённое состояние в соответствующем файле config приводит к тому что Ansible протоколирует свои действия в тот файл, который определён в значении установки log_path config.

Установка переменной ANSIBLE_LOG_PATH в значение некоторого пути, в который может осуществлять запись исполняющий ansible-playbook пользователь, также вызовет ведение протокола Ansible по этому пути. Значение многословности такой регистрации соответствует той многословности, с которой выполняется вывод на экран. При уровне многословности первого уровня (-v), возвращаемые данные отображаются на экране (и потенциально в вашем локальном файле log). При уровне многословности, поднятом до третьего уровня (-vvv), имеющийся вывод параметров также может отображаться. Поскольку они могут содержать секретную информацию, установка параметра no_log также применима к отображению на экран. Давайте возьмём свой предыдущий пример отображения зашифрованной секретной информации и добавим некий ключ no_log к своему заданию чтобы предотвратить отображение его значений:

---
- name: show me an encrypted var
  hosts: localhost
  gather_facts: false

  vars_files:
    - a_vars_file.yaml

  tasks:
    - name: print the variable
      debug:
        var: something
      no_log: true
 	   

Если мы исполним этот плейбук, мы должны обнаружить, что наши секретные данные защищены:

Как вы можете видеть, Ansible сам выполняет цензуру для предотвращения показа чувствительных данных.

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

Вы изучили как применять инструмент ansible-vault для защиты чувствительных данных через создание и редактирование зашифрованных файлов, их модификации, а также различные методы, доступные для предоставления соответствующего пароля Vault, в том числе приглашение на ввод пользователя, получение некого пароля из файла и запуск какого- то сценария для его выборки. Вы также изучили как смешивать зашифрованные строки с открытыми файлами YAML и как это упрощает планирование плйбука. Наконец, вы изучили рабочие стороны применения Ansible Vaults, тем самым предотвращая утечку данных в файлы remote log или от вывода на экраны.

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