Managing Certificates

Since the module can't currently manage certificates directly, you might want to consider the roles and profiles pattern.

In a very simplified version, the tree ends up looking something like

production/
├── dist
|   └── profile
|       ├── files
|       │   └── host_cert.pem
|       └── manifests
|           ├── base.pp
|           └── filebeat.pp
├── manifests/
|   └── site.pp
└── modules
    ├── apt/
    ├── filebeat/
    ├── powershell/
    ├── remote_file/
    └── stdlib/

filebeat.pp might look something like:

# A profile to manage filebeat, included in the base role
class profile::filebeat {

  file { '/etc/ssl/certs/host_cert.pem':
    ensure => file,
    source => "puppet:///modules/${module_name}/host_cert.pem",
  }

  file { '/etc/ssl/private/host_key.key':
    ensure  => file,
    content => hiera('host_key'),
  }

  class {'filebeat':
    outputs => {
      elasticsearch => {
        hosts => [
          'http://elasticsearch.example.com:9200',
        ],
        index => 'filebeat',
        tls   => {
          certificate_authorities => ['/etc/ssl/certs/ca-certificates.crt'],
          certificate             => '/etc/ssl/certs/host_cert.pem',
          certificatekey          => '/etc/ssl/private/host_key.key',
        },
      },
    },
  }

}

This example uses the system CA list that we manage separately, but certificate_authorities can just as easily be managed directly like the other files. The key file is kept in hiera so that it can be encrypted in our git repo (we use hiera-eyaml), but still deployed with r10k.

The filebeat profile is part of the base profile that's then included on all nodes. Individual prospectors are set up as part of application profiles (e.g. the webserver profile sets up a prospector to watch apache logs)