Code Monkey home page Code Monkey logo

hiera-eyaml's Introduction

Hiera eyaml

License Test codecov Release RubyGem Version RubyGem Downloads

hiera-eyaml is a backend for Hiera that provides per-value encryption of sensitive data within yaml files to be used by Puppet.


๐Ÿ†• hiera-eyaml is now part of Vox Pupuli

hiera-eyaml has a new home https://github.com/voxpupuli/hiera-eyaml.

Hopefully this will mean more frequent feature updates and bug fixes!

Advantages over hiera-gpg

A few people found that hiera-gpg just wasn't cutting it for all use cases, one of the best expressed frustrations was written back in June 2013. So Tom created an initial version and this was refined into an elegant solution over the following months.

Unlike hiera-gpg, hiera-eyaml:

  • only encrypts the values (which allows files to be swiftly reviewed without decryption)
  • encrypts the value of each key individually (this means that git diff is meaningful)
  • includes a command line tool for encrypting, decrypting, editing and rotating keys (makes it almost as easy as using clear text files)
  • uses basic asymmetric encryption (PKCS#7) by default (doesn't require any native libraries that need to be compiled & allows users without the private key to encrypt values that the puppet master can decrypt)
  • has a pluggable encryption framework (e.g. GPG encryption (hiera-eyaml-gpg) can be used if you have the need for multiple keys and easier key rotation)

The Hiera eyaml backend uses yaml formatted files with the .eyaml extension. The encrypted strings are prefixed with the encryption method, wrapped with ENC[] and placed in an eyaml file. You can mix your plain values in as well or separate them into different files. Encrypted values can occur within arrays, hashes, nested arrays and nested hashes.

For instance:

---
plain-property: You can see me

encrypted-property: >
    ENC[PKCS7,Y22exl+OvjDe+drmik2XEeD3VQtl1uZJXFFF2NnrMXDWx0csyqLB/2NOWefv
    NBTZfOlPvMlAesyr4bUY4I5XeVbVk38XKxeriH69EFAD4CahIZlC8lkE/uDh
    jJGQfh052eonkungHIcuGKY/5sEbbZl/qufjAtp/ufor15VBJtsXt17tXP4y
    l5ZP119Fwq8xiREGOL0lVvFYJz2hZc1ppPCNG5lwuLnTekXN/OazNYpf4CMd
    /HjZFXwcXRtTlzewJLc+/gox2IfByQRhsI/AgogRfYQKocZgFb/DOZoXR7wm
    IZGeunzwhqfmEtGiqpvJJQ5wVRdzJVpTnANBA5qxeA==]

To edit this you can use the command eyaml edit important.eyaml which will decrypt the file, fire up an editor with the decrypted values and re-encrypt any edited values when you exit the editor. This tool makes editing your encrypted files as simple as clear text files.

Setup

Installing hiera-eyaml

RubyGems

$ gem install hiera-eyaml

Apt (Ubuntu 18.04+)

$ sudo apt install hiera-eyaml

Installing hiera-eyaml for puppetserver

All commands need to be executed as root. Puppet Enterprise vendors hiera-eyaml already, so you don't need to install it there.

puppetserver gem install hiera-eyaml

or via puppet:

puppet resource package hiera-eyaml ensure=installed provider=puppetserver_gem

or via Puppet DSL:

package { 'hiera-eyaml':
  ensure   => 'installed',
  provider => 'puppetserver_gem',
}

Generate keys

The first step is to create a pair of keys:

$ eyaml createkeys

This creates a public and private key with default names in the default location. (./keys)

Storing the keys securely when using Puppet

Since the point of using this module is to securely store sensitive information, it's important to store these keys securely. If using Hiera with Puppet, Your puppetmaster will need to access these keys to perform decryption when the puppet agent runs on a remote node. So for this reason, a suggested location might be to store them in /etc/puppetlabs/puppet/eyaml or /var/lib/puppet/keys depending on your setup.

The permissions for this folder should allow the puppet user (normally 'puppet') execute access to the keys directory, read only access to the keys themselves and restrict everyone else:

$ chown -R puppet:puppet /etc/puppetlabs/puppet/eyaml
$ chmod -R 0500 /etc/puppetlabs/puppet/eyaml
$ chmod 0400 /etc/puppetlabs/puppet/eyaml/*.pem
$ ls -lha /etc/puppetlabs/puppet/eyaml
-r-------- 1 puppet puppet 1.7K Sep 24 16:24 private_key.pkcs7.pem
-r-------- 1 puppet puppet 1.1K Sep 24 16:24 public_key.pkcs7.pem

You may also load the keypair into an environment variable and use the pkcs7_private_key_env_var and pkcs7_public_key_env_var options to specify the environment variable names to avoid writing the secret key to disk.

Basic usage

Encryption

To encrypt something, you only need the public_key, so distribute that to people creating hiera properties

$ eyaml encrypt -f filename            # Encrypt a file
$ eyaml encrypt -s 'hello there'       # Encrypt a string
$ eyaml encrypt -p                     # Encrypt a password (prompt for it)

Use the -l parameter to pass in a label for the encrypted value,

$ eyaml encrypt -l 'some_easy_to_use_label' -s 'yourSecretString'

Decryption

To decrypt something, you need the private_key.

To test decryption you can use the eyaml tool

$ eyaml decrypt -f filename               # Decrypt a file
$ eyaml decrypt -s 'ENC[PKCS7,.....]'     # Decrypt a string

Editing files with a mixture of eyaml-encrypted and plain-text content

This is, perhaps, the most common use of eyaml where you have created a few eyaml files, with a mixture of encrypted and non-encrypted properties, you can edit the encrypted values in place, using the special edit mode of the eyaml utility. Edit mode opens a decrypted copy of the eyaml file in your $EDITOR and will encrypt and modified values when you exit the editor.

$ eyaml edit filename.eyaml         # Edit an eyaml file in place

When editing eyaml files, you will see that the unencrypted plaintext is marked to allow the eyaml tool to identify each encrypted block, along with the encryption method. This is used to make sure that the block is encrypted again only if the clear text value has changed, and is encrypted using the original encryption mechanism (see plugable encryption later).

A decrypted file might look like this:

---
plain-property: You can see me

cipher-property : >
    DEC(1)::PKCS7[You can't see me]!

environments:
    development:
        host: localhost
        password: password
    production:
        host: prod.org.com
        password: >
            DEC(2)::PKCS7[securepassword]!

things:
    - thing 1
    -   - nested thing 1.0
        - >
            DEC(3)::PKCS7[secure nested thing 1.1]!
    -   - nested thing 2.0
        - nested thing 2.1

Whilst editing you can delete existing values and add new one using the same format (as below). Note that it is important to omit the number in brackets for new values. If any duplicate IDs are found then the re-encryption process will be abandoned by the eyaml tool.

some_new_key: DEC::PKCS7[a new value to encrypt]!

Encrypting an entire file

While not as common, sometimes you need to encrypt an entire file. Maybe this file is binary data that isn't meant for loading into an editor. One example might be a Kerberos keytab file. No problem! Just encrypt the entire file:

$ eyaml encrypt -f filename

As with encrypting short strings on the command-line, the encrypted equivalent will be sent to stdout as an ASCII text string and thus now plays nice with your editor. Notice that the file itself, however, remains unchanged. The output is presented in two blocks: once as a single, long string and once in a nice line-wrapped form. Copy the one of your preference, starting with the ENC[ and ending at the matching ]. Paste this into your Puppet or Hiera file just like any other eyaml string and your done. If the file is rather large, you may wish to use a helper like xclip to copy the stdout directly to your clipboard.

Encrypting multiline values

The following step-by-step example shows you how to encrypt multiline values.

  • Copy the YAML text below to a file named multiline_example.eyaml
---
accounts::key_sets:
  dummy:
    private: |
      ---- BEGIN SSH2 ENCRYPTED PRIVATE KEY ----
      Comment: "dummy-key-hiera-eyaml-issue-rsa-key-20200911"
      P2/56wAAANwAAAA3aWYtbW9kbntzaWdue3JzYS1wa2NzMS1zaGExfSxlbmNyeXB0e3JzYS
      1wa2NzMXYyLW9hZXB9fQAAAARub25lAAAAjQAAAIkAAAAGJQAAAP93ZtrMIRZutZ/SZUyw
      JWwyI4YxNvr5tBt9UnSJ7K0+rQAAAQDohO1ykUahsogS+ymM6o9WEmdROJZpWShCqdv8Dj
      2roQAAAIDG1G8hY90Xlz/YiFhDZLLWAAAAgOzMWTfAlHbJ4AdEhG5uU/EAAACA+1/AlcSr
      QEPM5xLW0unCsQ==
      ---- END SSH2 ENCRYPTED PRIVATE KEY ----
  • Use edit to ...
    • replace '|' with '>',
    • prepend DEC::PKCS7[ before the first line,
    • remove all whitespaces used for indentation,
    • and append ]! to the last line of the multiline value.

eyaml edit multiline_example.eyaml

---
accounts::key_sets:
  dummy:
    private: >
      DEC::PKCS7[---- BEGIN SSH2 ENCRYPTED PRIVATE KEY ----
Comment: "dummy-key-hiera-eyaml-issue-rsa-key-20170123"
P2/56wAAANwAAAA3aWYtbW9kbntzaWdue3JzYS1wa2NzMS1zaGExfSxlbmNyeXB0e3JzYS
1wa2NzMXYyLW9hZXB9fQAAAARub25lAAAAjQAAAIkAAAAGJQAAAP93ZtrMIRZutZ/SZUyw
JWwyI4YxNvr5tBt9UnSJ7K0+rQAAAQDohO1ykUahsogS+ymM6o9WEmdROJZpWShCqdv8Dj
2roQAAAIDG1G8hY90Xlz/YiFhDZLLWAAAAgOzMWTfAlHbJ4AdEhG5uU/EAAACA+1/AlcSr
QEPM5xLW0unCsQ==
---- END SSH2 ENCRYPTED PRIVATE KEY ----]!
# resulting encrypted file
---
accounts::key_sets:
  dummy:
    private: >
      ENC[PKCS7,MIIDTQYJKoZIhvcNAQcDoIIDPjCCAzoCAQAxggEhMIIBHQIBADAFMAACAQEw
      DQYJKoZIhvcNAQEBBQAEggEAXH7xB1xuzoMAqA/3jSXO0ZUR6+UCb3DsTTj3
      Lsrcx5oQBnJ/ml7GfBCPxBKfArZunLcnxmSk4hECKXdfgKsVjAa++JQWvtEm
      HUNTFqvwd76Ku+nMfI9c8g+X+l6obLjzWfJdg3t6Ja7CJKl8UNFtSmbfYKVi
      nZ0xBubgdY4plLAFcZyD5/A/lNFqwb051TRLbZOIRRfLUlRL7RNkKRC59Aog
      S5aJXjmqx6vRzFifNK0JFZvYHGD75TiHJ5LFjg4rjgFd43AnK8iNo773ZWP2
      48Gly5Zx7qVQDCDDi1YBgNFb0NIBQw+kWy7HcPH2REvPnXu/HV2FWvDP3Ond
      yr2EbTCCAg4GCSqGSIb3DQEHATAdBglghkgBZQMEASoEEH+CjZJ1gKfaQIrr
      N5zef7OAggHgBmRVsfaoiNEOzhmHZ5SxxZztmpBNtLv7mteaSqSL5o0TtKQh
      SDgxBhaQmlL51+JM1Jsnvqm57ikZhj7Vtek/vr5DhYhWs0AxttH5rNaw0zKU
      4bMppVu+SNKCtT+2Qw31x/S7gF7yVl+mwmXhq3qAj9ExWRX3d/8/zTuC61Io
      f+7O6YUOucZ/m/YPrQnC5v7bDSKlIf1aFaKqukjM3QO8FZlAOHGPvRuWV2Om
      QIgxQE6F8r+bTkW3KiVIx5FEIthRZ90VS3tz/2wjj77svddBhlid9ov/0ard
      GGVNGsl1BFpLqxC0mpZXz237cL/aM58naqmX52J6YmC0xQM3DNmahWlYx1HV
      J/Ogk12pOYPLJB/09OuoHPzKC4WfpB9B7wAC6pghRkO/84cOw6rgSdbzze5W
      WMPvo181Y74BSBKhJDdO3lWYmEcDyx4TEsMUlpxd9PBDcOHqf9qHviXrwGzO
      oSm2bUV0Fum5ueU+D2vu3mO0yIQ6fwyvDZLBRjfJV7K/PyDz81feWT6+g38t
      AC27c0h8wk9b7HYfqG28nZE7F13qrhwCKnOaYLglsmbszNpRrBhfo1IHF6oM
      YZRZrnrGQg5qQcxMsLq37RAfRgkY0rRLs78EEAhkf4NDxw0A/ovt]
  • Output of eyaml decrypt -f multiline_example.eyaml:
---
accounts::key_sets:
  dummy:
    private: |
  ---- BEGIN SSH2 ENCRYPTED PRIVATE KEY ----
  Comment: "dummy-key-hiera-eyaml-issue-rsa-key-20200911"
  P2/56wAAANwAAAA3aWYtbW9kbntzaWdue3JzYS1wa2NzMS1zaGExfSxlbmNyeXB0e3JzYS
  1wa2NzMXYyLW9hZXB9fQAAAARub25lAAAAjQAAAIkAAAAGJQAAAP93ZtrMIRZutZ/SZUyw
  JWwyI4YxNvr5tBt9UnSJ7K0+rQAAAQDohO1ykUahsogS+ymM6o9WEmdROJZpWShCqdv8Dj
  2roQAAAIDG1G8hY90Xlz/YiFhDZLLWAAAAgOzMWTfAlHbJ4AdEhG5uU/EAAACA+1/AlcSr
  QEPM5xLW0unCsQ==
  ---- END SSH2 ENCRYPTED PRIVATE KEY ----
  • The output does NOT have to be valid YAML for usage with Puppet.

Hiera

To use eyaml with hiera and puppet, first configure hiera.yaml to use the eyaml backend.

Eyaml works with Hiera 3.x, as well as with Hiera 5 (Puppet 4.9.3 and later).

With Hiera 5

In Hiera 5, each hierarchy level has one designated backend, as well as its own independent configuration for that backend.

Hierarchy levels that use eyaml must set the following keys:

  • name.

  • lookup_key (must be set to eyaml_lookup_key).

  • path/paths/glob/globs (choose one).

  • datadir (can be omitted if you've set a default).

  • options โ€”ย a hash of eyaml-specific settings; by default, this should include pkcs7_private_key and pkcs7_public_key, or pkcs7_public_key_env_var and pkcs7_private_key_env_var, but alternate encryption plugins use alternate options. Anything from the old :eyaml config section (except datadir) goes here.

    You do not need to specify key names as :symbols; normal strings are fine.

---
version: 5
defaults:
  datadir: data
hierarchy:
  - name: "Secret data: per-node, per-datacenter, common"
    lookup_key: eyaml_lookup_key # eyaml backend
    paths:
      - "secrets/nodes/%{trusted.certname}.eyaml"  # Include explicit file extension
      - "secrets/location/%{facts.whereami}.eyaml"
      - "common.eyaml"
    options:
      pkcs7_private_key: /etc/puppetlabs/puppet/eyaml/private_key.pkcs7.pem
      pkcs7_public_key:  /etc/puppetlabs/puppet/eyaml/public_key.pkcs7.pem
  - name: "Normal data"
    data_hash: yaml_data # Standard yaml backend
    paths:
      - "nodes/%{trusted.certname}.yaml"
      - "location/%{facts.whereami}/%{facts.group}.yaml"
      - "groups/%{facts.group}.yaml"
      - "os/%{facts.os.family}.yaml"
      - "common.yaml"

Unlike with Hiera 3, there's no default file extension for eyaml files, so you can specify your own file extension directly in the path name.

For more details, see the hiera.yaml (version 5) reference page.

With Hiera 3

In Hiera 3, hierarchy levels don't have a backend assigned to them, and Hiera loops through the entire hierarchy for each backend. Options for the backend are set globally, in an :eyaml config section.

---
:backends:
    - eyaml
    - yaml

:hierarchy:
    - %{environment}
    - common

:yaml:
    :datadir: '/etc/puppet/hieradata'
:eyaml:
    :datadir: '/etc/puppet/hieradata'

    # If using the pkcs7 encryptor (default)
    :pkcs7_private_key: /path/to/private_key.pkcs7.pem
    :pkcs7_public_key:  /path/to/public_key.pkcs7.pem

    # Optionally cache decrypted data (default: false)
    :cache_decrypted: false

Then, edit your hiera yaml files, and insert your encrypted values. The default eyaml file extension is .eyaml, however this can be configured in the :eyaml block to set :extension,

:eyaml:
    :extension: 'yaml'

Data formatting note

Important Note: The eyaml backend will not parse internally json formatted yaml files, whereas the regular yaml backend will. You'll need to ensure any existing yaml files using json format are converted to syntactically correct yaml format.

---
plain-property: You can see me

cipher-property : >
    ENC[PKCS7,Y22exl+OvjDe+drmik2XEeD3VQtl1uZJXFFF2NnrMXDWx0csyqLB/2NOWefv
    NBTZfOlPvMlAesyr4bUY4I5XeVbVk38XKxeriH69EFAD4CahIZlC8lkE/uDh
    jJGQfh052eonkungHIcuGKY/5sEbbZl/qufjAtp/ufor15VBJtsXt17tXP4y
    l5ZP119Fwq8xiREGOL0lVvFYJz2hZc1ppPCNG5lwuLnTekXN/OazNYpf4CMd
    /HjZFXwcXRtTlzewJLc+/gox2IfByQRhsI/AgogRfYQKocZgFb/DOZoXR7wm
    IZGeunzwhqfmEtGiqpvJJQ5wVRdzJVpTnANBA5qxeA==]

environments:
    development:
        host: localhost
        password: password
    production:
        host: prod.org.com
        password: >
            ENC[PKCS7,Y22exl+OvjDe+drmik2XEeD3VQtl1uZJXFFF2NnrMXDWx0csyqLB/2NOWefv
            NBTZfOlPvMlAesyr4bUY4I5XeVbVk38XKxeriH69EFAD4CahIZlC8lkE/uDh
            jJGQfh052eonkungHIcuGKY/5sEbbZl/qufjAtp/ufor15VBJtsXt17tXP4y
            l5ZP119Fwq8xiREGOL0lVvFYJz2hZc1ppPCNG5lwuLnTekXN/OazNYpf4CMd
            /HjZFXwcXRtTlzewJLc+/gox2IfByQRhsI/AgogRfYQKocZgFb/DOZoXR7wm
            IZGeunzwhqfmEtGiqpvJJQ5wVRdzJVpTnANBA5qxeA==]

things:
    - thing 1
    -   - nested thing 1.0
        - >
            ENC[PKCS7,Y22exl+OvjDe+drmik2XEeD3VQtl1uZJXFFF2NnrMXDWx0csyqLB/2NOWefv
            NBTZfOlPvMlAesyr4bUY4I5XeVbVk38XKxeriH69EFAD4CahIZlC8lkE/uDh
            jJGQfh052eonkungHIcuGKY/5sEbbZl/qufjAtp/ufor15VBJtsXt17tXP4y
            l5ZP119Fwq8xiREGOL0lVvFYJz2hZc1ppPCNG5lwuLnTekXN/OazNYpf4CMd
            /HjZFXwcXRtTlzewJLc+/gox2IfByQRhsI/AgogRfYQKocZgFb/DOZoXR7wm
            IZGeunzwhqfmEtGiqpvJJQ5wVRdzJVpTnANBA5qxeA==]
    -   - nested thing 2.0
        - nested thing 2.1

Configuration file for eyaml

Default parameters for the eyaml command line tool can be provided by creating a configuration YAML file.

Config files will be read in following order:

  • first from system-wide /etc/eyaml/config.yaml
  • then from user home directory ~/.eyaml/config.yaml
  • then from current working directory .eyaml/config.yaml
  • finally by anything referenced in the EYAML_CONFIG environment variable

The file takes any long form argument that you can provide on the command line. For example, to override the pkcs7 keys:

---
pkcs7_private_key: './keys/eyaml/private_key.pkcs7.pem'
pkcs7_public_key: './keys/eyaml/public_key.pkcs7.pem'

Or to override to use GPG by default:

---
encrypt_method: 'gpg'
gpg_gnupghome: './alternative_gnupghome'
gpg_recipients: '[email protected],[email protected],[email protected]'

Pluggable Encryption

hiera-eyaml backend is pluggable, so that further encryption types can be added as separate gems to the general mechanism which hiera-eyaml uses. Hiera-eyaml ships with one default mechanism of 'pkcs7', the encryption type widely used to sign smime email messages.

Other encryption types (if the gems for them have been loaded) can be specified using the following formats:

ENC[PKCS7,SOME_ENCRYPTED_VALUE]         # a PKCS7 encrypted value
ENC[GPG,SOME_ENCRYPTED_VALUE]           # a GPG encrypted value (hiera-eyaml-gpg)
... etc ...

When editing eyaml files, you will see that the unencrypted plaintext is marked in such a way as to identify the encryption method. This is so that the eyaml tool knows to encrypt it back using the correct method afterwards:

some_key: DEC(1)::PKCS7[very secret password]!

Encryption plugins

This is a list of available plugins:

  • hiera-eyaml-gpg - Provide GPG encryption
  • hiera-eyaml-plaintext - This is a no-op encryption plugin that simply base64 encodes the values. It exists as an example plugin to create your own and to do integration tests on hiera-eyaml. THIS SHOULD NOT BE USED IN PRODUCTION
  • hiera-eyaml-twofac - PKCS7 keypair + AES256 symmetric password for two-factor encryption Note that this plugin mandates the user enter a password. It is useful for non-automated scenarios, and is not advised to be used in conjunction with puppet, as it requires entry of a password over a terminal.
  • hiera-eyaml-kms - Encryption using AWS Key Management Service (KMS)
  • hiera-eyaml-gkms - Encryption using Google Cloud KMS
  • hiera-eyaml-vault - Use the transit secrets engine from Vault for providing encryption.

How-To's:

Notes

If you do not specify an encryption method within ENC[] tags, it will be assumed to be PKCS7

Also remember that after encrypting your sensitive properties, if anyone has access to your git source, they will see what the property was in previous commits before you encrypted. It's recommended that you roll any passwords when switching from unencrypted to encrypted properties. eg, Developers having write access to a DEV branch will be able to read/view the contents of the PRD branch, as per the design of GIT.

Github has a great guide on removing sensitive data from repos here: https://help.github.com/articles/remove-sensitive-data

Troubleshooting

Installing from behind a corporate/application proxy

$ export HTTP_PROXY=http://yourcorporateproxy:3128/
$ export HTTPS_PROXY=http://yourcorporateproxy:3128/

then run your install

$ gem install hiera-eyaml

Issues

If you have found a bug then please raise an issue here on github.

Some of us hang out on #voxpupuli on Libera.Chat, please drop by if you want to say hi or have a question.

Tests

NOTE Some testing requirements are not supported on Windows

In order to run the tests, simply run cucumber in the top level directory of the project.

You'll need to have a few requirements installed:

  • expect (via yum/apt-get or system package)
  • aruba (gem)
  • cucumber (gem)
  • puppet (gem)
  • hiera-eyaml-plaintext (gem)

Authors

hiera-eyaml's People

Contributors

alexjfisher avatar antoinesebert avatar bastelfreak avatar cmd-ntrf avatar crayfishx avatar davidsansome avatar dependabot[bot] avatar dhollinger avatar elyscape avatar geekpete avatar ghoneycutt avatar glennsarti avatar gmsharky avatar gtmtech avatar kbite avatar kenyon avatar micmax93 avatar nferch avatar peculater avatar petems avatar pschrammel avatar quixoten avatar rnelson0 avatar robbat2 avatar rooprob avatar sigv avatar sihil avatar stlava avatar tompoulton avatar vinzent avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

hiera-eyaml's Issues

Error 400 on SERVER: Could not find data item levent_parent_upload_dir in any Hiera data file and no default supplied

Hi,

I have:
3.4.3 (Puppet Enterprise 3.2.0)
Welcome to eyaml 2.0.2
CentOS release 6.5 (Final)

hiera.yaml


:backends:

  • eyaml
  • yaml
    :hierarchy:
  • defaults
  • "%{clientcert}"
  • "%{environment}/jdk"
  • "%{environment}/jboss"
  • "%{environment}/mathematica"
  • global

:yaml:
:datadir: /etc/puppetlabs/puppet/hieradata
:eyaml:
:datadir: /etc/puppetlabs/puppet/hieradata
:pkcs7_private_key: /etc/puppetlabs/puppet/secure/keys/private_key.pkcs7.pem
:pkcs7_public_key: /etc/puppetlabs/puppet/secure/keys/public_key.pkcs7.pem

levent.eyaml

levent_parent_upload_dir : /data/puppet
levent_installation_file : levent.sh
levent_target_dir : /opt/levent
levent_activation_key : levent
levent_test_eyaml_levent: >
ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQEw
DQYJKoZIhvcNAQEBBQAEggEAKN5vaOYzrAhBZQZJdpNj0p2QcM2EUq4c8Sqz
UcV91nkKm7O9i0s4VAFu2ueH0sZwLG6bqVVk2ZWt/rnDc5tdyMQhJOVwhxxY
WWwJLrPqyByuMQTVF2MeXsO/PU5UJ5TEiZuq8x50O2ZJCHXL+TuiU10xPEOn
kbI6vNBfYo6/axhOuDW+UN+KBQV7QbC14FoJDR/Q3WJ8LEgBHnAZvI3U13jU
MecSCh8kK6/YP1223pTgE494TwaJ5yOWe1wOAxbbEDlie/1qr5XGX7qjMjZX
FULCVew/A65ZaajiWMMzV0KJj4r5oWeaTLgstpOvCSr4k1vvbaAPfDCXRU6E
6AloyjA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBBOJv9YAF5XNmbfHKFt
eJObgBCIy5NWOyDa0DbVaYSWa8M6]

puppet agent is installed on a different host without hiera-eyaml.
It looks like eyaml does not work since it should by default look at .eyaml files.

When I configure it to read yaml files, password will not be decrypted.

When I call, eyaml edit levent.eyaml, I can see the password as stated in documentation.

Only from puppet-hiera will it not work, any ideas?

hiera-eyaml gem should work with system hiera (and not require rubygem hiera)

Hello, I created rpms to install the hiera-eyaml gems (my work environment requires this) using fpm.

I have the puppetlabs hiera installed, and would prefer to stick with the puppetlabs version.

# rpm -qa |grep hiera
hiera-1.3.0-1.el6.noarch

which installs to:
/usr/lib/ruby/site_ruby/1.8/hiera

When I install the rubygems (rubygem-hiera-eyaml-2.0.1-1.noarch, rubygem-highline-1.6.21-1.noarch, rubygem-trollop-2.0.0-1.noarch) and try and use eyaml, I get:

# eyaml createkeys
/usr/lib/ruby/site_ruby/1.8/rubygems.rb:779:in `report_activate_error': Could not find RubyGem hiera (>= 1.2.1) (Gem::LoadError)
from /usr/lib/ruby/site_ruby/1.8/rubygems.rb:214:in `activate'
from /usr/lib/ruby/site_ruby/1.8/rubygems.rb:249:in `activate'
from /usr/lib/ruby/site_ruby/1.8/rubygems.rb:248:in `each'
from /usr/lib/ruby/site_ruby/1.8/rubygems.rb:248:in `activate'
from /usr/lib/ruby/site_ruby/1.8/rubygems.rb:1082:in `gem'
from /usr/bin/eyaml:18

I tried to symlink /usr/lib/ruby/site_ruby/1.8/hiera to /usr/lib/ruby/gems/1.8/gems/hiera-1.3.0 to no avail.

I can install fine doing a normal gem install, but the gem install overwrites the system hiera binary, and because the gem overwrites /usr/bin/hiera the next time puppetlabs updates their hiera rpm it's going to overwrite the gem binary and possibly cause problems.

Let me know if there is any other information you require.

Have a good day.

-Shawn

traditional yaml no longer being processed

Hi there,

I've just started to use .eyaml files and it seems that the "old" .yaml files are no longer being processed if/when there is a .eyaml file ?

Is it not possible to mix eyaml with normal yaml files ? Not every yaml config file will contain sensitive data.

Thanks!
Alex

decrypt_action.rb:58:in `parse_encryption_scheme': undefined method `default_encryption_scheme' for Hiera::Backend::Eyaml:Module (NoMethodError)

Trying to use hiera-eyaml 1.3.2 installed from rubygems
Command line decryption is working fine:

eyaml --pkcs7-private-key /root/hiera_private_key.pem -k /root/hiera_public_key.pem -d -f /vagrant/hieradata/common.eyaml 

But when trying to retrieve file with hiera receive following exception:

hiera -d -c /vagrant/hiera.yaml gerrit::mysql_password role='gerrit'
DEBUG: Tue Sep 03 14:03:59 +0200 2013: [eyaml_backend]: Lookup called for key gerrit::mysql_password
DEBUG: Tue Sep 03 14:03:59 +0200 2013: Cannot find datafile /vagrant/hieradata/roles/gerrit.eyaml, skipping
DEBUG: Tue Sep 03 14:03:59 +0200 2013: [eyaml_backend]: Processing datasource: /vagrant/hieradata/common.eyaml
DEBUG: Tue Sep 03 14:03:59 +0200 2013: [eyaml_backend]: Data contains valid YAML
DEBUG: Tue Sep 03 14:03:59 +0200 2013: [eyaml_backend]: Key gerrit::mysql_password found in YAML document
DEBUG: Tue Sep 03 14:03:59 +0200 2013: [eyaml_backend]: Attempting to decrypt: gerrit::mysql_password
DEBUG: Tue Sep 03 14:03:59 +0200 2013: [eyaml_backend]: Setting: pkcs7_private_key = /root/hiera_private_key.pem
DEBUG: Tue Sep 03 14:03:59 +0200 2013: [eyaml_backend]: Setting: pkcs7_public_key = /root/hiera_public_key.pem
DEBUG: Tue Sep 03 14:03:59 +0200 2013: [eyaml_backend]: Setting: datadir = /vagrant/hieradata
/usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.2/lib/hiera/backend/eyaml/actions/decrypt_action.rb:58:in `parse_encryption_scheme': undefined method `default_encryption_scheme' for Hiera::Backend::Eyaml:Module (NoMethodError)
    from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.2/lib/hiera/backend/eyaml/actions/decrypt_action.rb:43:in `execute'
    from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.2/lib/hiera/backend/eyaml/actions/decrypt_action.rb:42:in `gsub'
    from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.2/lib/hiera/backend/eyaml/actions/decrypt_action.rb:42:in `execute'
    from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.2/lib/hiera/backend/eyaml_backend.rb:101:in `decrypt'
    from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.2/lib/hiera/backend/eyaml_backend.rb:98:in `gsub'
    from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.2/lib/hiera/backend/eyaml_backend.rb:98:in `decrypt'
    from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.2/lib/hiera/backend/eyaml_backend.rb:64:in `parse_answer'
    from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.2/lib/hiera/backend/eyaml_backend.rb:31:in `lookup'
    from /usr/lib/ruby/site_ruby/1.8/hiera/backend.rb:68:in `datasources'
    from /usr/lib/ruby/site_ruby/1.8/hiera/backend.rb:66:in `map'
    from /usr/lib/ruby/site_ruby/1.8/hiera/backend.rb:66:in `datasources'
    from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.2/lib/hiera/backend/eyaml_backend.rb:18:in `lookup'
    from /usr/lib/ruby/site_ruby/1.8/hiera/backend.rb:182:in `lookup'
    from /usr/lib/ruby/site_ruby/1.8/hiera/backend.rb:179:in `each'
    from /usr/lib/ruby/site_ruby/1.8/hiera/backend.rb:179:in `lookup'
    from /usr/lib/ruby/site_ruby/1.8/hiera.rb:64:in `lookup'
    from /usr/bin/hiera:220

my hiera.yaml looks like:

:hierarchy:
...
:backends:
  - eyaml
  - yaml
:yaml:
  :datadir: '/vagrant/hieradata'
:eyaml:
  :datadir: '/vagrant/hieradata'
  :pkcs7_private_key: /root/hiera_private_key.pem
  :pkcs7_public_key:  /root/hiera_public_key.pem

Same stuff worked for hiera-eyaml 1.1.4

Location of keys

Hi,

Just curious why the secure keys are left in the /etc/puppet directory?

Puppet uses a location under /var/lib/puppet

I have no issues with it was just wondering if it was a conscious decision for some reason.

Config file to define key location

Currently when trying to encrypt files it looks in ./keys/ for the private/public keys.

This cause problems with changing directory and trying to edit files without specifying them with -r and -r.

This could be defined in a $HOME/.eyaml.conf file or similar? Or globally in /etc/?

Error during lookup

Hi, I tried to implement this in my puppet code and I'm getting following error

Debug: hiera(): [eyaml_backend]: Lookup called for key value-encryption-test
Debug: hiera(): [eyaml_backend]: Processing datasource: /etc/puppet/hieradata/vm.local.eyaml
Error: Could not run: (): could not find expected ':' while scanning a simple key at line 19 column 1

And I assume it's about *.eyaml file which on 19 line has

value-encryption-test: >
ENC[Gx7ys+HTjAgPJU7y4xHQloTy8YvFvKIU7pf4Hf8BcKefWbCV2AkxVnUP+NNC
NKOsgVpBJhZXx1acULhJg0y7YKvm2e6XjEZPqulb1iU8s5XwVK0HjG0YMsLd
6Bg2wU6lEB/BIVjzjorGmj4RRGW9ZPKTew0LCjFzo7jfTIbvOC4MC0n+OyjV
RbXzJoQ8/kQMT/jrnSLRxa9W1xrsEQQqX340A/iKb1O+Lf4FRaby069V2imR
EZVSWEvRb2jeEBUb2jrBKB2cXbOBGin2zIZ6ty6bS3+VM1nuC+AYzYTq6wkv
wL2mgBYin/JWlSyZ2LRlzB9h3xdZFoVvmzMHSXSJfA==]

I'd appreciate any ideas on what could be wrong here.

Thanks

undefined local variable or method `msg' for Hiera::Backend::Eyaml::Utils:Class

I'm having decryption problems using hiera-eyaml-gpg, but the error that is being thrown is not helpful:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Puppet::Parser::AST::Resource failed with error NameError: undefined local variable or method `msg' for Hiera::Backend::Eyaml::Utils:Class at /etc/puppetlabs/puppet/environments/cxd_bld01/modules/cis/manifests/boot_settings.pp:24 on node cxdbld01app0101
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

It appears to be coming from warn function in lib/hiera/backend/eyaml/utils.rb, line 143:

        def self.warn messageinfo
          message = self.structure_message messageinfo
          message = "[#{message[:from]}] !!! #{message[:msg]}"
          if self.hiera?
            Hiera.warn format_message msg
          else
            STDERR.puts message
          end
        end

If I replace msg with 'msg' (ie. a string), I get a different error:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Puppet::Parser::AST::Resource failed with error NoMethodError: undefined method `format_message' for Hiera::Backend::Eyaml::Utils:Class at /etc/puppetlabs/puppet/environments/cxd_bld01/modules/cis/manifests/boot_settings.pp:24 on node cxdbld01app0101
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

If I then replace format_message with 'format_message' (ie. a string, again), I get a more helpful error:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Puppet::Parser::AST::Resource failed with error GPGME::Error::DecryptFailed: GPGME::Error::DecryptFailed at /etc/puppetlabs/puppet/environments/cxd_bld01/modules/cis/manifests/boot_settings.pp:24 on node cxdbld01app0101
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

I'm sure what the correct fix is - can I leave it with you?

Keep use of same keys type

Hi,

since the newest update I've got problems with updating my existing environments.
Before only private key was required for decryption, and now since it need public as well it doesn't accept it in the format I've created them (following instructions here)
throwing "nested asn1 error"

in eyaml_backend.rb

public_key_pem = File.read( public_key_path )
public_key = OpenSSL::X509::Certificate.new( public_key_pem )

I think it should be

public_key = OpenSSL::PKey::RSA.new( public_key )

to be compatible with existing deployments.
Is there any specific reason this has been changed?

Cheers,
Piotr

Puppet can't decrypt hiera variable

I'm using Puppet 3.5.0. Hiera 1.3.2. Eyaml 2.0.1. Oracle Linux 6.5.

I followed the documentation and everything works as expected, except the encrypted string doesn't get unencrypted during the puppet run.

I created a simple file type and a string variable in hiera. The problem is when I run "puppet agent -t" it just puts the actual encrypted string in place, not the unencrypted text.

In other words, this:

hostname.yaml
test: ENC[PR............VggBD652vwNiSvudBq6wuyHRpn]

eyaml edit hostname.yaml
test: DEC(1)::PKCS7[hello]!

file { '/tmp/test.txt':
ensure => present,
content => $test,
}

ends up with contents:
ENC[PR............VggBD652vwNiSvudBq6wuyHRpn]

and not:
hello

My hiera.yaml section:
:eyaml:
:datadir: /etc/puppet/hieradata
:extension: yaml
:pkcs7_private_key: /etc/puppet/secure/keys/private_key.pkcs7.pem
:pkcs7_public_key: /etc/puppet/secure/keys/public_key.pkcs7.pem

It would be great to get this working. Any thoughts?
Thanks,
Kent

Editing multiple values fails with CentOS 6.5 and system default Ruby 1.8.7

with hiera-eyaml 2.0.2 on CentOS 6.5 latest updates.

create simple eyaml with:

eyaml encrypt -l 'test_password' -s 'password1234' >> common.eyaml

cat common.eyaml
test_password: ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQEwDQYJKoZIhvcNAQEBBQAEggEAV+kmvArZ4Sf0NMcOUvEuxaKnUAY/TNIo4KTWD1obN7KIEPNCDsBryTdFuj5z4+7CTm0ONIhykjB22BDv/XV0TelL4U+ZtXReqTgBtbGM3+KDh/t6t/lbqKNczKLLYmSvFs2jhgy4Ghh1xj/1Mk+i7PP3yq//lByUsFqmeG6EFrg92jcH47hByHMS04w70NO26jTmH+VqzLU3oql+9RyFl2mEZ2mgTJi3jH47QYoxfaVLYH3kBuHTMYmGSYQzL5tG16oGKpWaiuH5VkfyZnVASalvlb5xO4c/X1HdRhRg3QDuTSjfzjFK0vOsINb+esNAZmWuA9fijlbRvy/k+T0WwDA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBBugUfpDY3QIj+qQ5y6DtjogBAna/xVM/tqXymnf4XvAcPh]

OR

test_password: >
ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQEw
DQYJKoZIhvcNAQEBBQAEggEAV+kmvArZ4Sf0NMcOUvEuxaKnUAY/TNIo4KTW
D1obN7KIEPNCDsBryTdFuj5z4+7CTm0ONIhykjB22BDv/XV0TelL4U+ZtXRe
qTgBtbGM3+KDh/t6t/lbqKNczKLLYmSvFs2jhgy4Ghh1xj/1Mk+i7PP3yq//
lByUsFqmeG6EFrg92jcH47hByHMS04w70NO26jTmH+VqzLU3oql+9RyFl2mE
Z2mgTJi3jH47QYoxfaVLYH3kBuHTMYmGSYQzL5tG16oGKpWaiuH5VkfyZnVA
Salvlb5xO4c/X1HdRhRg3QDuTSjfzjFK0vOsINb+esNAZmWuA9fijlbRvy/k
+T0WwDA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBBugUfpDY3QIj+qQ5y6
DtjogBAna/xVM/tqXymnf4XvAcPh]

Edit the eyaml and delete the first value and add a yaml header thingy:

eyaml edit common.eyaml

cat common.eyaml

test_password: >
ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQEw
DQYJKoZIhvcNAQEBBQAEggEAV+kmvArZ4Sf0NMcOUvEuxaKnUAY/TNIo4KTW
D1obN7KIEPNCDsBryTdFuj5z4+7CTm0ONIhykjB22BDv/XV0TelL4U+ZtXRe
qTgBtbGM3+KDh/t6t/lbqKNczKLLYmSvFs2jhgy4Ghh1xj/1Mk+i7PP3yq//
lByUsFqmeG6EFrg92jcH47hByHMS04w70NO26jTmH+VqzLU3oql+9RyFl2mE
Z2mgTJi3jH47QYoxfaVLYH3kBuHTMYmGSYQzL5tG16oGKpWaiuH5VkfyZnVA
Salvlb5xO4c/X1HdRhRg3QDuTSjfzjFK0vOsINb+esNAZmWuA9fijlbRvy/k
+T0WwDA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBBugUfpDY3QIj+qQ5y6
DtjogBAna/xVM/tqXymnf4XvAcPh]

Edit the eyaml again and add a second value:

(vim window looks like this:

test_password: >
DEC(1)::PKCS7[password1234]!
prod_password: >
DEC(2)::PKCS7[4321drowssap]!

Save the file and get this error:

eyaml edit common.eyaml
[hiera-eyaml-core] Loaded config from /root/.eyaml/config.yaml
[hiera-eyaml-core] !!! undefined method plain_text' for #<Hiera::Backend::Eyaml::Parser::NonMatchToken:0x7f16ab7dedf8> [hiera-eyaml-core] ["/usr/lib/ruby/gems/1.8/gems/hiera-eyaml-2.0.2/lib/hiera/backend/eyaml/subcommands/edit.rb:70:inexecute'", "/usr/lib/ruby/gems/1.8/gems/hiera-eyaml-2.0.2/lib/hiera/backend/eyaml/subcommands/edit.rb:67:in map'", "/usr/lib/ruby/gems/1.8/gems/hiera-eyaml-2.0.2/lib/hiera/backend/eyaml/subcommands/edit.rb:67:inexecute'", "/usr/lib/ruby/gems/1.8/gems/hiera-eyaml-2.0.2/lib/hiera/backend/eyaml/CLI.rb:45:in execute'", "/usr/lib/ruby/gems/1.8/gems/hiera-eyaml-2.0.2/bin/eyaml:13", "/usr/bin/eyaml:19:inload'", "/usr/bin/eyaml:19"]

(common.eyaml still looks the same as the previous cat output, nothing was saved)

Empty eyaml fails puppet runs with strange error

If you have any empty .eyaml files you get strange errors on puppet runs:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: undefined method `empty?' for false:FalseClass at /etc/puppet/manifests/nodes_something.pp:3 on node hostname.coolplace.com
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

How are users encrypting private keys

Can hiera-eyaml be used to encrypt ssh private keys for use in hiera, or is it not possible?

I want to be able to keep ssh private keys in the git repo, but want them obfuscated.

Thanks,
Tom

when creating keys, permissions should be more restrictive on private key.

I think the permissions should be 640 by default? perhaps it should also try change the ownership to puppet:puppet if that user exists on box otherwise root:root?

# eyaml -c
/etc/hiera/keys/private_key.pem created.
/etc/hiera/keys/public_key.pem created.
# ls -l
total 8
-rw-r--r-- 1 root root 1675 Aug 14 10:45 private_key.pem
-rw-r--r-- 1 root root 1050 Aug 14 10:45 public_key.pem

Help text is misleading

eyaml createkeys --help outputs the following

   --pkcs7-private-key <s>:   Private key directory (default: ./keys/private_key.pkcs7.pem)
    --pkcs7-public-key <s>:   Public key directory (default: ./keys/public_key.pkcs7.pem)

The word "directory" is misleading, since what it actually wants is the full path to a file (as the default example shows).

Can't use edit mode (1.3.1)

Getting the following after upgrading to 1.3.1 and trying to edit a file using eyaml -i.

/var/lib/gems/1.8/gems/hiera-eyaml-1.3.1/lib/hiera/backend/eyaml/utils.rb:42:in delete': can't convert File into String (TypeError) from /var/lib/gems/1.8/gems/hiera-eyaml-1.3.1/lib/hiera/backend/eyaml/utils.rb:42:insecure_file_delete'
from /var/lib/gems/1.8/gems/hiera-eyaml-1.3.1/lib/hiera/backend/eyaml/actions/edit_action.rb:25:in execute' from /var/lib/gems/1.8/gems/hiera-eyaml-1.3.1/lib/hiera/backend/eyaml/CLI.rb:100:inexecute'
from /var/lib/gems/1.8/gems/hiera-eyaml-1.3.1/bin/eyaml:13
from /usr/local/bin/eyaml:19:in `load'
from /usr/local/bin/eyaml:19

default keys directory

@gtmtech I was messing around with eyaml just now creating keys and writing cucumber tests etc, anyway I put the following in a debug line in the create_keys method of pkcs7.rb to see where keys were being created by default:

Pathname.pwd + ' : ' + public_key

then built and installed the gem and got this output

/home/tom/[stuff]/github/hiera-eyaml/ : /keys/public_key.pkcs7.pem

What is the default directory for keys meant to be, and also why would it default to a path inside my github repo after I've installed it as a gem?

Apologies if this is just the way gems work, I'm still new to this ruby stuffs

Do you think it would make sense to use /etc/hiera/keys or something as a default seeing as most of the time hiera-eyaml will be used via hiera?

BTW the cucumber tests are great, really useful for trying stuff out!

The -r option only works some of the time

This is pretty weird. I'm assuming this is due to hash order randomization?

[[email protected] ~]#  eyaml -e -r /etc/hiera/keys/private_key.pem -k /etc/hiera/keys/public_key.pem  -o block -p  foo
Enter password: ***
    ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQAw
    DQYJKoZIhvcNAQEBBQAEggEAsGrtWLcc8L+ShTE22jSMLXwcmdKRkQ5Lu9Je
    Jr1596/DMK7cmIGsGokeY15bmAO5GXG/PcCyliEZi0hmR5woBBbuefKa67NN
    peD0fFuv7aQmXHeWXRUkPfPYm7OgJthZYGmRsVUckKpsE47Sk5ZbMbPqBFQ0
    3IDxVD93v8SQ7FHb69s6erpxWVv9hVXf+/BFYMVmI+yZeXf/KMK+cxQvlESp
    n/RhdxRvXN0s5v8cVU7yIFI80l22atvs3+DDK41dHL8N2md8O20xKuDkHOA3
    /2n92XIiGoQ7Rmk7wT/YGgCLkBxFYo6rldZVQOEEbWkiDpLEgMwYF8t0DXN6
    mbXhszA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBDQD8SGwxmo6luXO9eu
    XadTgBCN5JeHXP+t6YhS4dgm370Z]
[[email protected] ~]#  eyaml -e -r /etc/hiera/keys/private_key.pem -k /etc/hiera/keys/public_key.pem  -o block -p  foo
Error: unknown argument '-r'.
Try --help for help.
[[email protected] ~]#  eyaml -e -r /etc/hiera/keys/private_key.pem -k /etc/hiera/keys/public_key.pem  -o block -p  foo
Error: unknown argument '-r'.
Try --help for help.
[[email protected] ~]#  eyaml -e -r /etc/hiera/keys/private_key.pem -k /etc/hiera/keys/public_key.pem  -o block -p  foo
Enter password: ***
    ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQAw
    DQYJKoZIhvcNAQEBBQAEggEAUUPbMbyLny5U/GHvJM+PjUntMW9ov42yaVc4
    YA9KEMuyGPKuBX3hTPueCdvOsHBL2SsfZzi3Qta0d6alJH2Llc+7VQ53R/Sf
    ibUsr57Xwne43cmLjjYSkIHrySF7nOuBx0xTtWvtxwLJIGG3my/HnQuN59sn
    CikRPPeVX1NYLFgjhqGC4/ByVNeSQ6sXoSUDppLDvTavy17um9JrfymvG0+a
    +lFEstgXirvsVzyNNT/EopjRTXZzqTaMEXYChkV4RcMHlq6VjH///5NgL0du
    x/STy1hH04XuYroSCTYbrAPoSAkuNwshLvGsqg2SMPn2z0h4lePwBC0qFb2Z
    Up/HYjA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBB3/1k0O75f4hcNLR3y
    0Bi9gBCYsiK4AfekoBmj0rFicYZF]

(version 1.3.4)

Project Updates

Hi @gtmtech and @sihil, I created this to track general project stuff that isn't specific to a particular issue.

First notice is that I've started adding lightweight tags to the commits that correspond to releases, as commits that update the version number aren't necessarily the last commit to be included in the build. Basically I just did git tag v1.3.5 which means we can now use git tag to get a list of commits corresponding to versions and git show v1.3.5 to get the commit info for that version.

It might be useful for something, mainly I just added it to play around, but we should continue to do it on future versions.

spurious whitespace when re-encrypting blocks

With the new eyaml parser from I'm seeing the cipher text indented each time on the blocks you don't update

eyaml -i test_input.yaml

update a random key just to trigger a file diff on save, and diff, and notice the blocks are now more indented.

I can see eyaml/parser/encrypted_tokens.rb to_encrypted() adds this indentation, and I'm considering suggesting just dropping it. I'm still unwinding these changes from my 1.3.4 fix to find a better solution.

ciphertext = @cipher.gsub(/\n/, "\n" + @indentation)
+++ b/features/sandbox/test_input.yaml
@@ -1,33 +1,35 @@
 simple_string: how do you do
 encrypted_string: ENC[PKCS7,MIIBiQYJKoZIhvcNAQcDoIIBejCCAXYCAQAxggEhMIIBHQIBADAFMAACAQAwDQYJKoZIhvcNAQEBBQAEggEAgld+r
-encrypted_default_encryption_string: ENC[MIIBiQYJKoZIhvcNAQcDoIIBejCCAXYCAQAxggEhMIIBHQIBADAFMAACAQAwDQYJKoZIhvcNAQEB
+encrypted_default_encryption_string: ENC[PKCS7,MIIBiQYJKoZIhvcNAQcDoIIBejCCAXYCAQAxggEhMIIBHQIBADAFMAACAQAwDQYJKoZIhv

 simple_block: >
     once upon a time
     in a galaxy far far
     away
+    the original three
+    are the best

 encrypted_block: >
     ENC[PKCS7,MIIBiQYJKoZIhvcNAQcDoIIBejCCAXYCAQAxggEhMIIBHQIBADAFMAACAQAw
-    DQYJKoZIhvcNAQEBBQAEggEAYzeWn3MBLhOs4hokxMCWcDd9VuwCylQRUQ0w
-    KwCObeORw8PJkCDvi5ZIA2YkrvYTT6u3/7KfAiHd0Rg1WLb9et0Mg/Fd3DFF
-    7qhqOGHoQt3+4eKzlcikeR0/Lqrq2vTpqZ2Sw1CZ7Dn+Z4ll95p7lp97rb2J
-    kYTVroLYGWEcsS3JZLL4/l3z0bJbXNKKqJ1aHCAFq+wmWXeb6cDvvyHFg2N/
-    vGPFEQjP7AbWhxHxXDbYIGcU073u5NtE40JXL8SH82iHxqRF8s9g6Dh5cmjg
-    AY2pkBD9e6N78NNx+PAJswsFAV4DOCbXdf2BisyYbM3na35MVfyb6ggDegrE
-    ebOxxDBMBgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBCWeGlYS5cQoX78L6LK
-    /mczgCD/pI7usp1XPebnN8CngxHXuUjj5S+6IUpOW6l2JgUeWw==]
+            DQYJKoZIhvcNAQEBBQAEggEAYzeWn3MBLhOs4hokxMCWcDd9VuwCylQRUQ0w
+            KwCObeORw8PJkCDvi5ZIA2YkrvYTT6u3/7KfAiHd0Rg1WLb9et0Mg/Fd3DFF
+            7qhqOGHoQt3+4eKzlcikeR0/Lqrq2vTpqZ2Sw1CZ7Dn+Z4ll95p7lp97rb2J

^^^^^^^^^ indent grows each save

Array/Hash value pickup problem

(not exhibited by cucumber tests), arrays and hashes do not work properly in hiera/puppet run situations.

The reason for this is the eyaml_backend integration class, which propogates the key down to parse_answer, but does not repropogate it when recursively calling itself for array and hash situations

hiera-eyaml doesn't play nice with heira_hash() 3.2.3

I just started evaluating hiera-eyaml and hit a glitch. It seems that any attempt to read a hash in an eyaml file using hiera_hash(), produces an error:
"Error 400 on SERVER: Resolution type is hash but parsed_answer is a Hash" The error occurs even if the hash does not contain any encrypted values. One more detail:

  • hiera( 'somehash' ) works fine
  • hiera_hash( 'somehash' ) fails

I'm using heira-eyaml 2.0.0 on puppet 3.2.3. Has anyone seen this before?

The following code snippets should reproduce the problem:

file: my_hiera.eyaml
somehash:
foo: this is just a string

code:
$a = hiera( 'somehash') # This succeeds
$b = hiera_hash('somehash') # This fails

Tracking encrypted blocks in edit mode

I'd like to improve the edit mode, and pave the way for the gpg module.

I think it's quite important that when editing a EYAML file that we do not re-encrypt blocks that have not been edited (this will make diffs work much better). In order to achieve this, it must be possible to uniquely identify a block in the edit mode and compare it later.

I was thinking something like DEC(4b2a562f)::GPG[content goes here]! Duplicate ID's will fail when re-encoding (if people copy and paste) and throw the user back into their editor.

eyaml will store the original (encrypted and decrypted) data blocks for each tag in memory whilst editing. It can then compare them during re-encryption and reuse anything that hasn't changed.

In addition, GPG recipients are encoded in the source encryption and should be carried over when re-encrypted unless overridden. This can be implemented either by hooking onto the unique tags or by adding the recipients directly (I prefer the former).

It should be a low impact change as only the transient decrypted format is being modified.

%{::environment} should work for the :eyaml: section

in the hiera.yaml

specifying
:datadir: /etc/puppet/environments/${environment}

works

specifying
:datadir: /etc/puppet/environments/${::environment}

does not work.

In the hierarchy bit:
:hierarchy:
- ${::environment}

works.

This is inconsistent for the file.

Have a good day.

-Shawn

deeper merge - use case

We make lots of hiera_hash lookups which are hierarchically merged which in turn contain any string, array or hash. We expect :merge_behavior :deeper. When using other hiera backends, we need them to support this behaviour.

rooprob@850e978

This patch takes hiera 1.2.1 merge behaviour, and makes it optional for eyaml users. I also added configuring the extension from eyaml; we use "yaml".

RFC. Test cases pending.

Ability to specify defaults in a $HOME/.eyaml file

Had a few comments from users saying that when using the eyaml tool, its frustrating to always have to use command line args to specify alternative locations of keys, as the default is ./keys - meaning that they always have to cd to a directory before running eyaml command line.

They suggest a $HOME/.eyaml file which can provide sensible defaults for some variables. I think this is a good idea.

Problem using hiera-eyaml

I am trying to use hiera-eyaml and have followed the README instructions.

eyaml seems to work, I can encrypt and decrypt files and passwords.

I can also use hiera -c to get at an encrypted value like so:

hiera -c /etc/puppetlabs/puppet/hiera.yaml rootpwd

But when running this simple test module it fails with cannot find the data item rootpwd defined in hieradata/defaults.eyaml.

class test {
$test = hiera('test')
$rootpwd = hiera('rootpwd')
notify { "Test: ${test}": }
}
If I just have the test variable defined in defaults.yaml it works fine. So it cannot find the defaults.eyaml file.

Here is my hiera.yaml:


:backends:

  • yaml
  • eyaml
    :hierarchy:
    • defaults
    • "%{clientcert}"
    • "%{environment}"
    • global
      :yaml:
      :datadir: /etc/puppetlabs/puppet/modules/hieradata
      :eyaml:
      :datadir: /etc/puppetlabs/puppet/modules/hieradata
      :pkcs7_private_key: /etc/puppetlabs/puppet/secure/keys/private_key.pkcs7.pem
      :pkcs7_public_key: /etc/puppetlabs/puppet/secure/keys/public_key.pkcs7.pem

And my defaults.eyaml file:


rootpwd: >
ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQAwDQYJKoZIhvcNAQE ...]
Any hints will be greatly appreciated.

I am running Puppet Enterprise 3.1.0 on Ubuntu 12.04.

Ability to change default private key path

./keys is not a sensible default private key path.

It would be good to be able to set your own default key path rather than running --pkcs7-private-key or creating a bash alias to do so.

Perhaps eyaml edit could read from ~/.eyaml/config or similar?

Add GPG encryption

Following on from discussion in issue #3 it seems that there are benefits to using GPG over those provided by the current PKCS#7 implementation.

However, it should be implemented as a separate plugin so that hiera-eyaml doesn't depend on the ruby-gpgme bindings (because the native code needs gcc when installing the gem).

re-encryption - a use case

Hi,

Just updated to 1.3.6.
At the weekend I was working on supporting re-encryption based on 1.3.4. I'm using hiera-eyaml-gpg and periodically need to encrypt my whole hieradata to support staff changes, each with their own key. We have dozens of hiera files, with hundreds of encrypted keys. The enc blobs must change to cover changes in recipient public keys (GPG plugin).

As I'm a ruby noob I hacked the edit/save to take a --force option to save on unchanged, simply bypassing the "No changes" exception. I set EDITOR=cat to avoid an editor. That was hackish but worked as POC.

I like the new parser, and tests. It's clearly much nicer to support recrypt as a first order function via the new parser than abusing EDITOR. What's different is now the blobs don't pass through encryption just because the file changes. IMO this is a good thing, in the normal case I don't want to pollute a file full of changes when only one item changes. However I still need a --recrypt-all type option to cover my recipient change case.

I will reply to myself in the next few hours if I figure this out.

Thanks for reading,

hiera fails to use eyaml

[[email protected] ~]# hiera -c /etc/puppet/hiera.yaml root_pw_hash
/usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.4/lib/hiera/backend/eyaml/actions/decrypt_action.rb:58:in `parse_encryption_scheme': undefined method `default_encryption_scheme' for Hiera::Backend::Eyaml:Module (NoMethodError)
        from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.4/lib/hiera/backend/eyaml/actions/decrypt_action.rb:43:in `execute'
        from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.4/lib/hiera/backend/eyaml/actions/decrypt_action.rb:42:in `gsub'
        from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.4/lib/hiera/backend/eyaml/actions/decrypt_action.rb:42:in `execute'
        from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.4/lib/hiera/backend/eyaml_backend.rb:101:in `decrypt'
        from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.4/lib/hiera/backend/eyaml_backend.rb:98:in `gsub'
        from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.4/lib/hiera/backend/eyaml_backend.rb:98:in `decrypt'
        from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.4/lib/hiera/backend/eyaml_backend.rb:64:in `parse_answer'
        from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.4/lib/hiera/backend/eyaml_backend.rb:31:in `lookup'
        from /usr/lib/ruby/site_ruby/1.8/hiera/backend.rb:68:in `datasources'
        from /usr/lib/ruby/site_ruby/1.8/hiera/backend.rb:66:in `map'
        from /usr/lib/ruby/site_ruby/1.8/hiera/backend.rb:66:in `datasources'
        from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.4/lib/hiera/backend/eyaml_backend.rb:18:in `lookup'
        from /usr/lib/ruby/site_ruby/1.8/hiera/backend.rb:182:in `lookup'
        from /usr/lib/ruby/site_ruby/1.8/hiera/backend.rb:179:in `each'
        from /usr/lib/ruby/site_ruby/1.8/hiera/backend.rb:179:in `lookup'
        from /usr/lib/ruby/site_ruby/1.8/hiera.rb:64:in `lookup'
        from /usr/bin/hiera:220

Could this have something to do with having two backend classes? (Hiera::Backend::Eyaml and Hiera::Backend::Eyaml_backend)

eyaml -c should handle /etc/hiera not exiting with proper error message.

It should have a better error message.

# eyaml -c

/usr/local/lib/ruby/gems/1.9.1/gems/hiera-eyaml-1.1.4/bin/eyaml:19:in `mkdir': No such file or directory - /etc/hiera/keys (Errno::ENOENT)
        from /usr/local/lib/ruby/gems/1.9.1/gems/hiera-eyaml-1.1.4/bin/eyaml:19:in `ensure_key_dir_exists'
        from /usr/local/lib/ruby/gems/1.9.1/gems/hiera-eyaml-1.1.4/bin/eyaml:133:in `<top (required)>'
        from /usr/local/bin/eyaml:23:in `load'
        from /usr/local/bin/eyaml:23:in `<main>'

puppet run fails with root:root 400 permissions on [public|private]_key.pkcs7.pem

When I perform a puppet run the decryption of eyaml data fails with the following error.

[vagrant@//redacted hostname// home]$ sudo puppet agent -t --noop
<< some puppet run output >>
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Permission denied - /var/lib/puppet/ssl/private_keys/private_key.pkcs7.pem at /etc/puppet/modules/users/manifests/init.pp:39 on node //redacted hostname//
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

If private_key.pkcs7.pem is chmod'ed to 404, the same error is thrown for public_key.pkcs7.pem until it is chmod'ed to 404, as well.

Permissions on the files when failure occurs are as follows.

-sh-4.1# readlink -f private_key.pkcs7.pem && ll private_key.pkcs7.pem
/var/lib/puppet/ssl/private_keys/private_key.pkcs7.pem
-r-------- 1 root root 1675 May 12 21:09 private_key.pkcs7.pem

-sh-4.1# readlink -f public_key.pkcs7.pem && ll public_key.pkcs7.pem
/var/lib/puppet/ssl/public_keys/public_key.pkcs7.pem
-r-------- 1 root root 1050 May 12 21:09 public_key.pkcs7.pem

I can decrypt the eyaml data via the command line, as follows.

[vagrant@//redacted hostname// ~]$ sudo hiera -c /etc/puppet/hiera.yaml root_password
//redacted, but correct, root password is displayed//

If I run the command without sudo I receive a read permission denied error on the private key file, as expected. However, curiously, running 'puppet agent -t' as root gives the same ERROR 400 during catalog compilation.

It is difficult to understand why read permissions for 'other' are needed when everything should be running as root.

merge hashes from different backends with puppet

Hello,

I have hiera with puppet configured to use yaml and eyaml backends. I have a hash configured in different data files, used with different backends. That is, keys with plain values are defined in common.yaml file and keys with encrypted values in the common.eyaml.

These are the files:


---
# common.eyaml

nsca::options:
  password: ENC[GPG,<encrypted key>]

---
# common.yaml

...
nsca::options:
  encryption_method: 2
# hiera.yaml
:backends:
  - eyaml
  - yaml
:yaml:
  :datadir: /etc/puppet/environments/%{::environment}/hieradata
:eyaml:
  :datadir: /etc/puppet/environments/%{::environment}/hieradata
  :extension: 'eyaml'
  :pkcs7_private_key: /etc/puppet/secure/keys/private_key.pkcs7.pem
  :pkcs7_public_key:  /etc/puppet/secure/keys/public_key.pkcs7.pem
  :gpg_gnupghome: '/etc/puppet/secure/gpg'
  :gpg_always_trust: true
:hierarchy:
  - "%{::fqdn}"
  - "%{::custom_location}"
  - common
:logger:  puppet
:merge_behaviour: deeper

In puppet (3.4) I'm using automating binding, but when I get options hash it only has passwordkey, but not encryption_method one. But when I test it with

# hiera -c ./hiera.yaml -h -d nsca::options
...
{"encryption_method"=>2, "password"=>"<plaintext password>"}

and it works.

Any idea?

edit mode cannot add multiple new values

If you do this it helpfully says:

A duplicate DEC(ID) was found so I don't know how to proceed. This is 
probably because you copy and pasted a value - if you do this please 
delete the ID in parentheses

This is a fail in the logic and should be fixed.

Cannot decrypt/edit PKCS7 eyaml files using JRuby

It seems that JRuby is not happy with the X509 Certificate (public key) generated by the eyaml command. Therefore, you cannot use hiera-eyaml with JRuby.

eyaml wants the cert to have an "issuer" (see below):

$ bin/eyaml edit test.eyaml
[hiera-eyaml-core] !!! Empty issuer DN not allowed in X509Certificates
[hiera-eyaml-core] ["org/jruby/ext/openssl/X509Cert.java:161:in initialize'", "/Users/clarence/.rbenv/versions/jruby-1.7.4/lib/ruby/gems/shared/gems/hiera-eyaml-2.0.0/lib/hiera/backend/eyaml/encryptors/pkcs7.rb:48:indecrypt'", "/Users/clarence/.rbenv/versions/jruby-1.7.4/lib/ruby/gems/shared/gems/hiera-eyaml-2.0.0/lib/hiera/backend/eyaml/parser/encrypted_tokens.rb:15:in encrypted_value'", "/Users/clarence/.rbenv/versions/jruby-1.7.4/lib/ruby/gems/shared/gems/hiera-eyaml-2.0.0/lib/hiera/backend/eyaml/parser/encrypted_tokens.rb:80:increate_enc_token'", "/Users/clarence/.rbenv/versions/jruby-1.7.4/lib/ruby/gems/shared/gems/hiera-eyaml-2.0.0/lib/hiera/backend/eyaml/parser/encrypted_tokens.rb:110:in create_token'", "/Users/clarence/.rbenv/versions/jruby-1.7.4/lib/ruby/gems/shared/gems/hiera-eyaml-2.0.0/lib/hiera/backend/eyaml/parser/parser.rb:71:inparse_scanner'", "/Users/clarence/.rbenv/versions/jruby-1.7.4/lib/ruby/gems/shared/gems/hiera-eyaml-2.0.0/lib/hiera/backend/eyaml/parser/parser.rb:74:in parse_scanner'", "/Users/clarence/.rbenv/versions/jruby-1.7.4/lib/ruby/gems/shared/gems/hiera-eyaml-2.0.0/lib/hiera/backend/eyaml/parser/parser.rb:36:inparse'", "/Users/clarence/.rbenv/versions/jruby-1.7.4/lib/ruby/gems/shared/gems/hiera-eyaml-2.0.0/lib/hiera/backend/eyaml/subcommands/edit.rb:36:in execute'", "/Users/clarence/.rbenv/versions/jruby-1.7.4/lib/ruby/gems/shared/gems/hiera-eyaml-2.0.0/lib/hiera/backend/eyaml/CLI.rb:45:inexecute'", "bin/eyaml:13:in `(root)'"]

Does not work with Puppet 3.5.1 (Hiera 1.3.2)

/etc/puppet# hiera secrets
/var/lib/gems/1.9.1/gems/hiera-eyaml-2.0.1/lib/hiera/backend/eyaml_backend.rb:19:in `initialize': undefined method `[]' for nil:NilClass (NoMethodError)
    from /var/lib/gems/1.9.1/gems/hiera-1.3.2/lib/hiera/backend.rb:172:in `new'
    from /var/lib/gems/1.9.1/gems/hiera-1.3.2/lib/hiera/backend.rb:172:in `block in lookup'
    from /var/lib/gems/1.9.1/gems/hiera-1.3.2/lib/hiera/backend.rb:170:in `each'
    from /var/lib/gems/1.9.1/gems/hiera-1.3.2/lib/hiera/backend.rb:170:in `lookup'
    from /var/lib/gems/1.9.1/gems/hiera-1.3.2/lib/hiera.rb:60:in `lookup'
    from /var/lib/gems/1.9.1/gems/hiera-1.3.2/bin/hiera:221:in `<top (required)>'
    from /usr/local/bin/hiera:19:in `load'
    from /usr/local/bin/hiera:19:in `<main>'

That's the error I receive when trying to simply list a hash. Let me know if you need anything else!

`eyaml -c` fails on 32 bit linux due to cert.not_after time being too large.

eyaml -c fails on 32-bit linux:

In the file: hiera-eyaml-1.3.4/lib/hiera/backend/eyaml/encryptors/pkcs7.rb:72
This is the line that causes the problem:

cert.not_after = Time.now + 50 * 365 * 24 * 60 * 60

After some Googling, it seems that 32-bit can only hold a Time up to the year 2038 (see: https://groups.google.com/forum/#!topic/comp.lang.ruby/VcZfhxUNXBU).

For example, if I change line 72 to:

cert.not_after = Time.now + 24 * 365 * 24 * 60 * 60

Then eyaml -c works fine.

Perhaps the not_after date should be an option rather than hard coded?

My ruby version is: ruby 1.9.3p448 (2013-06-27 revision 41675) [i686-linux]

Sample error output:

Are you sure you want to overwrite "./keys/private_key.pkcs7.pem"? (y/N): y
/opt/puppet/lib/ruby/gems/1.9.1/gems/hiera-eyaml-1.3.4/lib/hiera/backend/eyaml/encryptors/pkcs7.rb:72:in not_after=': bignum too big to convert intolong' (RangeError)
from /opt/puppet/lib/ruby/gems/1.9.1/gems/hiera-eyaml-1.3.4/lib/hiera/backend/eyaml/encryptors/pkcs7.rb:72:in create_keys' from /opt/puppet/lib/ruby/gems/1.9.1/gems/hiera-eyaml-1.3.4/lib/hiera/backend/eyaml/actions/createkeys_action.rb:14:inexecute'
from /opt/puppet/lib/ruby/gems/1.9.1/gems/hiera-eyaml-1.3.4/lib/hiera/backend/eyaml/CLI.rb:101:in execute' from /opt/puppet/lib/ruby/gems/1.9.1/gems/hiera-eyaml-1.3.4/bin/eyaml:13:in<top (required)>'
from /opt/puppet/bin/eyaml:23:in load' from /opt/puppet/bin/eyaml:23:in

'

License missing from gemspec

Some companies will only use gems with a certain license.
The canonical and easy way to check is via the gemspec,

via e.g.

spec.license = 'MIT'
# or
spec.licenses = ['MIT', 'GPL-2']

Even for projects that already specify a license, including a license in your gemspec is a good practice, since it is easily
discoverable there without having to check the readme or for a license file.

For example, there is a License Finder gem to help companies ensure all gems they use
meet their licensing needs. This tool depends on license information being available in the gemspec. This is an important enough
issue that even Bundler now generates gems with a default 'MIT' license.

If you need help choosing a license (sorry, I haven't checked your readme or looked for a license file),
github has created a license picker tool.

In case you're wondering how I found you and why I made this issue, it's because I'm collecting stats on gems (I was originally
looking for download data) and decided to collect license metadata,too, and make issues for gemspecs not specifying a license as a public service :).

I hope you'll consider specifying a license in your gemspec. If not, please just close the issue and let me know. In either case, I'll follow up. Thanks!

p.s. I've written a blog post about this project

Errors of yaml and no eyaml files exist. Fine if just eyaml files exist.

Hello, first off I am running:
CentOS 6.5
puppet-3.4.3-1.el6.noarch
puppet-server-3.4.3-1.el6.noarch

gem list
hiera (1.3.2)
hiera-eyaml (2.0.1)
highline (1.6.21)
json (1.5.5)
json_pure (1.8.1)
stomp (1.2.2)
trollop (2.0)

My hiera.yaml looks like this:


---
:backends:
 - eyaml
 - yaml

:yaml:
  :datadir: /etc/puppet/environments/%{environment}/hiera/

:eyaml:
  :datadir: /etc/puppet/environments/%{environment}/hiera/
  :pkcs7_private_key: /etc/puppet/secure/private_key.pkcs7.pem
  :pkcs7_public_key: /etc/puppet/environments/master/public_key.pkcs7.pem

:hierarchy:
  - %{::clientcert}
  - %{::environment}
  - %{::stage}
  - %{::location}
  - common

:logger: console

When I have .yaml files (and no eyaml files) in my hiera dir I get this error:

Error 400 on SERVER: Error from DataBinding 'hiera' while looking up 'repo::domain::url': undefined method `read_file' for #<Hiera::Filecache:0x7f9b1aae1b60 @cache={}> on node bla

If I either:
rename .yaml .eyaml *.yaml

OR if I disable eyaml from the hiera.yaml, everything works as it should.

Here is a --trace:
https://gist.github.com/shawn-sterling/9774519

If there is anything I can do to help further debug this issue let me know.

Have a good day.

-Shawn

bug in hiera 1.3.2-1 vs rubygem-hiera 1.3.2-1

While upgrading to eyaml 2.0.1 and puppet 3.4.3 using RPMs I encountered installation bug #80. While deciding how to work around this I uncovered a hidden difference between hiera and rubygem-hiera.

rubygem-hiera-1.3.2-1 works
hiera-1.3.2-1 fails with the error (see bottom) which implies that eyaml couldn't find the encrypted value.

This may be a manifestation of bug #82 bcuz I have both eyaml and yaml backends enabled.

My system is:
CentOS 6
puppet-3.4.3-1.el6.noarch
puppet-server-3.4.3-1.el6.noarch
fastthread (1.0.7)
hiera (1.3.2) --- in either hiera or rubygem-hiera incarnation
hiera-eyaml (2.0.1)
highline (1.6.20)
json (1.4.6)
json_pure (1.8.1)
rack (1.1.0)
rake (0.8.7)
trollop (2.0)


Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to parse template exim/tls-certificate.erb:
Filepath: /usr/lib/ruby/site_ruby/1.8/hiera_puppet.rb
Line: 14
Detail: Could not find data item exim_tls_certificate in any Hiera data file and no default supplied
at /etc/puppet/environments/dev22/modules/exim/manifests/config.pp:88 on node rx1-mail-flex-van.dev-globalrelay.net
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

Should be able to `edit` a new file

When I try to eyaml edit a new file, eyaml dies with ENOENT. It seems reasonable that I should be able to create a new file and have things encrypted from the start.

Improve the structure of the eyaml command

The eyaml command is a bit of a mess - I can never remember which option to use for editing or encrypting? -e? -y? -i?

Anyway, I'd like to propose that we introduce sub commands, as per git and here is some thinking about how it should work (not how we should implement it).

We'd have four (five for the new recrypt function in #44) commands:

eyaml createkeys
eyaml encrypt
eyaml decrypt
eyaml edit
eyaml recrypt

Then there would be some global options and options for each command. For example, the existing --encrypt-method option (-n) would be global, but settings like --string which only make sense for encrypt and decrypt will only be available for those commands.

I think this will make the command much friendlier - at the moment I have to try a couple of times before I try the right options. I want to get it right first time. Also, the automatically generated short options are unpredictable as is seen in #30.

Interested to hear what you think. I don't think this is too hard (with the exception of merging options from plugins) and am happy to have a bash at it sometime soon.

Problems when encrypting SSH keys

Error: Parameter key failed on Ssh_authorized_key[deploy_key]: Key must not contain whitespace: AAAAB3NzaC1yc2E(..)

And I'm pretty much sure I'm not inserting whitespace anywhere, and the value presented with the error exactly matches encrypted value.

Any ideas on what's going wrong?

Thanks,
Piotr

hiera-eyaml doesn't play nice with heira_hash() 3.0.1

I just started evaluating hiera-eyaml and hit a glitch. It seems that any attempt to read a hash in an eyaml file using hiera_hash(), produces an error:
"Error 400 on SERVER: Resolution type is hash but parsed_answer is a Hash" The error occurs even if the hash does not contain any encrypted values. One more detail:

  • hiera( 'somehash' ) works fine
  • hiera_hash( 'somehash' ) fails

I'm using heira-eyaml 2.0.0 on puppet 3.0.1. Has anyone seen this before?

The following code snippets should reproduce the problem:

file: my_hiera.eyaml
somehash:
foo: this is just a string

code:
$a = hiera( 'somehash') # This succeeds
$b = hiera_hash('somehash') # This fails

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.