Поиск марионетки завершается с ошибкой с ожиданием чувствительного значения, полученной строкой

Я пытаюсь внедрить зашифрованные значения в yaml в Hiera 5, чтобы безопасно вводить пароли в Puppet (предприятие) 5.3 с помощью автоматического поиска. Отличные рекомендации можно найти в блоге Puppet и PUP-7284 о необходимой настройке.

Однако я не могу понять lookup_options правильно, чтобы обеспечить преобразование в чувствительный тип (чтобы соответствовать параметрам класса).

Утверждение с помощью команды puppet lookup завершается ошибкой:

[user@rhel7 ~]$ puppet lookup my_module::db_pass --environment test --type Sensitive[String]
Error: Could not run: Found value has wrong type, expects a Sensitive value, got String

Также кажется, что найдены lookup_options. и выглядят разумно:

[user@rhel7 ~]$ puppet lookup my_module::db_pass --environment test --explain-options
Hierarchy entry "Passwords"
        Path "/etc/puppetlabs/code/environments/test/modules/my_module/data/secrets.eyaml"
          Original path: "secrets.eyaml"
          Found key: "lookup_options" value: {
            "^my_module::.*pass$" => {
              "convert_to" => "Sensitive"
            }
          }

Расшифровка работает просто отлично (к сожалению, для открытого текста - не уверен, что это ожидается?)

[user@rhel7 ~]$ puppet lookup my_module::db_pass --environment test
Found key: "my_module::db_pass" value: "password_is_taco"

Настройка выглядит следующим образом:

[user@rhel7 /etc/puppetlabs/puppet/environment/test/modules/my_module]$ cat hiera.eyaml
---
version: 5
defaults:
  data_hash: yaml_data
  datadir: data

hierarchy:
  - name: "Passwords"
    lookup_key: eyaml_lookup_key
    paths:
      - "secrets.eyaml"
    options:
        pkcs7_private_key: "/etc/puppetlabs/puppet/keys/private_key.pkcs7.pem"
        pkcs7_public_key: "/etc/puppetlabs/puppet/keys/public_key.pkcs7.pem"

[user@rhel7 /etc/puppetlabs/puppet/environment/test/modules/my_module]$ cat ./data/secrets.eyaml
---
lookup_options:
  '^my_module::.*pass$':
    convert_to: "Sensitive"

my_module::db_pass: >
    ENC[PKCS7,MIIBqQYJKoZ...snip]

Мне также не удалось использовать разные регулярные выражения и/или просто использовать ключи напрямую:

lookup_options:
  my_module::db_pass:
    convert_to: "Sensitive"

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


puppet hiera
person cbrwflo    schedule 30.01.2019    source источник
comment
Кстати, эта JIRA на самом деле для Hiera 4, которая была в основном бета-версией для Hiera 5. При этом на первый взгляд это выглядит так, как будто вам нужно перенести lookup_options из данных в конфигурацию. Я думаю, что правильно разместить конфигурацию hiera внутри данных, но, вероятно, было бы проще начать с размещения ее на уровне иерархии eyaml. В качестве примечания: когда я делаю что-то подобное, я обычно просто соглашаюсь с желанием Puppet искать зашифрованные пароли как String, а затем преобразовать в Sensitive перед любым отчетом/выводом. Это также может быть ошибкой в ​​бэкэнде eyaml.   -  person Matt Schuchard    schedule 30.01.2019
comment
@MattSchuchard, внутри данных не только допустимое место для lookup_options, но и подходящее место для параметров поиска. Они описывают свойства данных, а не источника(ов) данных. Более того, насколько я могу судить по docs, lookup_options не распознаются в основной конфигурации Hiera 5.   -  person John Bollinger    schedule 31.01.2019
comment
Попробуйте удалить data_hash: yaml_data из раздела defaults вашей конфигурации. Возможно, что наличие этого среди значений по умолчанию (и не переопределения для вашей иерархии eyaml) сбивает Hiera с использованием обычного yaml-сервера там, где вы хотите, чтобы он использовал eyaml. Если у вас есть другие уровни иерархии, на которых вы хотите использовать серверную часть yaml, добавьте ключ data_hash в конфигурацию каждого из них. Этот подход продемонстрирован в собственных документах бэкэнда eyaml, хотя я не уверен, что это так. собственно требуется.   -  person John Bollinger    schedule 31.01.2019
comment
Что ж, после того, как мое предположение было опровергнуто, теперь кажется более вероятным, что это ошибка.   -  person Matt Schuchard    schedule 31.01.2019
comment
Ty за помощь, похоже, я узнал больше о Hiera. Я попробовал предложение @John - не повезло. Я также попытался запустить Puppet Server на переднем плане, но не продвинулся дальше. Я узнал, что первый (и единственный) раз, когда анализируется lookup_options, происходит, когда модуль загружается (вероятно, кешируется на потом), это строка журнала ~ 800), тогда как автоматический поиск параметров для ключа db_pass происходит намного позже, около ~ 1100. Я бы не догадался об этом, основываясь на примечаниях по реализации в PUP-7675.   -  person cbrwflo    schedule 01.02.2019
comment
На данный момент я собираюсь принять предложение @Matt Schuchard, оставить параметр класса и продолжить реализацию модуля node_encrypt. Если позже у меня будет время вернуться, Кори Османа сообщение об отладке выглядит полезным.   -  person cbrwflo    schedule 01.02.2019

Ответы (1)


arrow_upward
2
arrow_downward

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

---
lookup_options:
  "^my_module::.*(password|token)$":
    convert_to: Sensitive

Сопоставление с шаблоном соответствующим образом приведет любое из следующих значений к Sensitive[String]:

my_module::password
my_module::service_password
my_module::api_token
my_module::any_number::of_subclasses::token_or_password

Если вы планируете пройти этот же процесс, вы можете подумать:

person cbrwflo    schedule 21.11.2020