same thing. works as soon as I remove the eyaml portion though

---
version: 5

defaults:  # Used for any hierarchy level that omits these keys.
  datadir: data         # This path is relative to hiera.yaml's directory.
  data_hash: yaml_data  # Use the built-in YAML backend.

hierarchy:
  - name: "osfamily/major release"
    paths:
        # Used to distinguish between Debian and Ubuntu
      - "os/%{facts.os.name}/%{facts.os.release.major}.yaml"
      - "os/%{facts.os.family}/%{facts.os.release.major}.yaml"
        # Used for Solaris
      - "os/%{facts.os.family}/%{facts.kernelrelease}.yaml"
  - name: "osfamily"
    paths:
      - "os/%{facts.os.name}.yaml"
      - "os/%{facts.os.family}.yaml"
  - name: 'common'
    path: 'common.yaml'
  - name: "secret data"
      lookup_key: eyaml_lookup_key # eyaml backend
      path: "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

This message was deleted.

same thing. works as soon as I remove the eyaml portion though

---
version: 5

defaults:  # Used for any hierarchy level that omits these keys.
  datadir: data         # This path is relative to hiera.yaml's directory.
  data_hash: yaml_data  # Use the built-in YAML backend.

hierarchy:
  - name: "osfamily/major release"
    paths:
        # Used to distinguish between Debian and Ubuntu
      - "os/%{facts.os.name}/%{facts.os.release.major}.yaml"
      - "os/%{facts.os.family}/%{facts.os.release.major}.yaml"
        # Used for Solaris
      - "os/%{facts.os.family}/%{facts.kernelrelease}.yaml"
  - name: "osfamily"
    paths:
      - "os/%{facts.os.name}.yaml"
      - "os/%{facts.os.family}.yaml"
  - name: 'common'
    path: 'common.yaml'
  - name: "secret data"
      lookup_key: eyaml_lookup_key # eyaml backend
      path: "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

That YAML hash syntax isn’t correct. There are too many spaces. You want this ☝️

LOL, working now thank you 😃

Can these be omitted and done at site level?

options:
      pkcs7_private_key: /etc/puppetlabs/puppet/keys/private_key.pkcs7.pem
      pkcs7_public_key: /etc/puppetlabs/puppet/keys/public_key.pkcs7.pem

Generally speaking, eyaml is never used at the module level. It’s more suited to the environment-layer or global layer of the Hierarchy. And one of the reasons is because of those keys…. it doesn’t make sense to have module-specific encryption keys.

This is a module i'm writing for provisioning a service account, so I'd prefer that the PW stay with the module?

To clarify, the eyaml backend configs and encrypted data live at the environment layer. But the plaintext data is usually used within a module.

To clarify, the eyaml backend configs and encrypted data live at the environment layer. But the encrypted data is usually used within a module.

To clarify, the eyaml backend configs and encrypted data live at the environment layer. But the plaintext data is usually used within a module.

so the ENC[PKCS7 , value would be module level then ?

Thanks, that seemed to work. site level config

---
version: 5

defaults:
  datadir: "hieradata"

hierarchy:
  - name: "Yaml backend"
    data_hash: yaml_data
    paths:
      - "nodes/%{trusted.certname}.yaml"
      - "common.yaml"
  - name: "EYaml Backend"
    lookup_key: eyaml_lookup_key # eyaml backend
    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

module

---
version: 5

defaults:  # Used for any hierarchy level that omits these keys.
  datadir: data         # This path is relative to hiera.yaml's directory.
  data_hash: yaml_data  # Use the built-in YAML backend.

hierarchy:
  - name: "osfamily/major release"
    paths:
        # Used to distinguish between Debian and Ubuntu
      - "os/%{facts.os.name}/%{facts.os.release.major}.yaml"
      - "os/%{facts.os.family}/%{facts.os.release.major}.yaml"
        # Used for Solaris
      - "os/%{facts.os.family}/%{facts.kernelrelease}.yaml"
  - name: "osfamily"
    paths:
      - "os/%{facts.os.name}.yaml"
      - "os/%{facts.os.family}.yaml"
  - name: 'common'
    path: 'common.yaml'
  - name: 'common-enc'
    path: 'common.eyaml'

```- took a dive. (Karma: -84)

Oh go pound sand mr bot.

The termination of backticks isn't exactly visible in the Slack client. There is visually NO difference between when it's properly closed or not which makes it hard to catch visually (as a human)

The termination of backticks isn't exactly visible in the Slack client. There is visually NO difference between when it's properly closed or not which makes it hard to catch visually (as a human)

I did perhaps speak too soon though, Looks like I had a lingering value in common.yaml which haddn't been saved so it was still getting the password from it.

Yup, you’ll need to think through the implications of having eyaml at the bottom of the hierarchy. By default, the higher-level items win over the lower-level items. I think I see eyaml at the top of the hierarchy more than I see it at the bottom. Though personally, I just always use the eyaml backend in my personal projects and name all my files

*.yaml

. That allows me to mix plaintext data with encrypted data in the same file.

The

eyaml

backend is able to return plaintext keys that aren’t encrypted. So it’s essentially the same as the

yaml

backend.

What would the module level hierarchy look like in hiera?

like this https://github.com/voxpupuli/puppet-prometheus/blob/master/hiera.yaml

like this https://github.com/voxpupuli/puppet-prometheus/blob/master/hiera.yaml

many examples https://www.google.com/search?client=firefox-b-1-d&q=github+voxpupuli+hiera.yaml

It typically isn’t the job of a module to define or care about how Hiera is configured at the environment level. The module just defines its inputs (i.e. class parameters) and maybe has some sane defaults in its own module-level heirarchy. The module is generic and it just wants some data fed into its class parameters. Using eyaml is a site-specific decision. How you encrypt your data, where those keys live, who has access, etc… is all a site-specific problem that applies to the entire Puppet environment. A module should not be in charge of those decisions. So typically your module-level hierarchy is super generic and your environment-level hierarchy is site specific and contains data/configs that only apply to your team’s/company’s use cases. So the environment-level data folder is where encrypted hiera data would live. Your module can still fetch data from Hiera, like an encrypted service account password, but it shouldn’t care where in hiera that data came from. Just that it exists at all.

Hmmm, Having a hard time telling whether the module is getting the encrypted data from hiera or not because the accounts module may not be setting the password correctly

I've even tried settings accounts::user - password to something stupidly easy '124password' and keep getting login incorrect

I've dumbed the password down to a static entry for testing purposes and whatever is getting set does not appear to be 124password

# @summary A short summary of the purpose of this class
#
# deploys the service account svcansiblelocal to linux hosts
# Requires the puppetlabs accounts and saz-sudo modules
#
# @example
#   include account_svcansiblelocal
class account_svcansiblelocal (
    String $user_password  
  ) {
  $user_name = 'svcansiblelocal'
  $user_groups = ['users']
  $user_comment = 'Service Account -  Ansible'
  $user_locked = false

  $user_purge_sshkeys = true
  $user_sshkeys = [
    'from="192.168.4.61" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCb08mJu9k0fBNL4y5MaxC2n8mo1JGdIKS0KcXn27rBblMo2JP9c7KbDwhUotxdCAHOZQzN21rQVMQJjGfzY2Qym2qWre54mOo1dIGHQk2GL2sy/ooTCdNRU/eFpdeF+VEDGORzh+X6280YdxubpWEvs81YmyxYZzZd0dKPlAg1bEbj4z5UHHzkQ4/EWe1vcBoFlJ8zSPvT31Jz7uRu/VOjs3qF4lmxbnLGzcrWoyI4yky3mxfoaL0/KqEVfWI1YL5MHmVBsmEa/leygsg/jhVPQNRSerATmEa3oXCY6EBsDuN60YdaS0Vo/E+qzT+5K8LpMMi/A6197SdUaPU0V+BP svcansiblelocal v1.00'
  ]
  $user_sudo_ensure = present
  $user_sudo_content = 'svcansiblelocal ALL=(ALL) NOPASSWD:ALL'

  
  accounts::user { "$user_name":
    comment       => $user_comment,
    groups        => $user_groups,
    password      => '124password',
    locked        => $user_locked,
    sshkeys       => $user_sshkeys,
    purge_sshkeys => $user_purge_sshkeys,
  }
  class privileges {
    sudo::conf { "$user_name":
      ensure  => $user_sudo_ensure,
      content => $user_sudo_content,
    }
  }
}

See the

saz-sudo

module at https://forge.puppet.com/saz/sudo?src=slack&channel=puppet