Puppet Community

Hi All! :question: How do i implement Puppet CA certname naming convention? Trying to add some restriction to Puppet CA. I currently have autosign enabled. want to take it a step further and only allow auto signing on certs that end with *.<http://example.com|example.com>

I'm using Puppet 8 open source i believe. the voxpupuli docker image. i created a `autosign.conf` file in `/etc/puppetlabs/puppet`  dir

doesn't seem to be working seeing it able to autosign certs that don't follow the allow certnames

And you need to configure autosign in the server section of puppet.conf

image.png

just one line: `<http://rebuilt.example.com|rebuilt.example.com>`

or use theforeman/puppet to configure it :slightly_smiling_face:

See the `theforeman-puppet` module at <https://forge.puppet.com/theforeman/puppet?src=slack&amp;channel=puppet>

the only configuration related to auto sign in puppet.conf is `autosign = true`

What was the common name in the certificate?

let say the common name is <http://rebuilt.example.com|rebuilt.example.com> . that should be the only cert it autosigns

Trying to essentially see if the process of blocking autosigning of certain certs is sound. More of a sanity check ... so the common name can be anything

it should indicate why it didn't autosign

sorry for the confusing ... the issue is not that it did not sign. the issue is that it did. according to the autosign.conf, it should only sign certs that look like `<http://rebuilt.example.com|rebuilt.example.com>` I did a `puppet agent -t`  on a test agent with certname other than the allowed `<http://rebuilt.example.com|rebuilt.example.com>` and it still signed it

okay figured it out! needed to update the `puppet.conf` file to put to the `autosign.conf` file. so updated `autosign = true` --&gt; `autosign = /etc/puppetlabs/puppet/autosign.conf`

thanks all for chiming in and getting me to think about this one

You are better of using some sort of script, like `/etc/puppetlabs/puppet/autosign.rb`

I get stuff from the certificate
```#!/opt/puppetlabs/puppet/bin/ruby
require 'puppet/ssl'

begin
  csr = Puppet::SSL::CertificateRequest.from_s(STDIN.read)```

yes yes. saw that as an option. if file given is not an executable, then it will default to an allow list file. like in my case. going to try the scripting route eventually but wanted to get something established and iterate on it. Puppet and ruby world is new to me so learning as i go!

Is there any reasonably “quick pass, not perfect but DECENT” way to identify a repo that has a puppet module?

For example, can a valid module be missing the manifests folder?

Or is there some better easy way to identify?  I noticed a lot of modules seem to be missing metadata.json from the root, just as an example, so I can’t seem to use that as a way to determine

Alternatively, is there something on the puppet server that shows the list of all modules it is aware of?

check <https://forge.puppet.com/> for quality score and number of downloads

I’ve got a GitLab server with a large number of repos, most of which are puppet modules (or so I’m told)

I’m trying to figure out if there is any good way to eliminate ones that aren’t ACTUALLY puppet modules

Decent? Look for a `manifests/init.pp` file or `manifests/` directory with `.pp` files in it.

Ok, thanks - that’s what I proposed above.

gee thats a low bar. nowadays I do expect unit-tests and acceptance test integrated in git-ci

Yeah, I’m being told this is a decade worth of puppet modules

`/etc/puppetlabs/code/environments/&lt;env&gt;/modules` on the Puppet server but that will (or should) include modules from the Forge.

Many from before good standards were put in place

the manifests dir is most likely, but metadata.json and Modulefile are both also good things to check for

Modulefile is the puppet2 version of the metadata.json

jk. but seriously you should consider demanding/enforcing tests for modules. IAC is software development and demands the same quality gates as everything else. after all your orchestrator (puppet) is root everywhere

Yeah, at work we are doing a major version upgrade of puppet

…which is necessitating the modules be updated/fixed

Short term, I suspect they are going to do minimum for now

Hopefully I can try to negotiate to bring them up to a certain standard

checking what's actually deployed on the puppetserver make more sense