Hi Matthias,
Yeah it was more as closest documentation I could find. I got some advice
that the main thing people looked for when publically exposed was to
prevent anyone being able to make CSR requests to the server which would be
on the configured in /etc/puppetlabs/puppetserver/conf.d/auth.conf
{
"allow-unauthenticated": true,
"match-request": {
"method": [
"get",
"put"
],
"path": "/puppet-ca/v1/certificate_request",
"query-params": {},
"type": "path"
},
"name": "puppetlabs csr",
"sort-order": 500
}
This should be disabled and something like puppetlabs/puppet-agent-bootstrap
(github.com) <https://github.com/puppetlabs/puppet-agent-bootstrap> used to
generate the certificates for communication. I'm afraid that I don't think
we have much as we generally avoid having publically exposed servers.
Thanks
David
On Friday, October 21, 2022 at 10:11:10 AM UTC+1 m...@webfactory.de wrote:
> Thank you for these suggestions.
>
> I might be missing something, but these patterns seem to link parts of the
> infrastructure at different locations/availablility zones through virtual
> private cloud links. I did not see if/how a Puppet Master is exposed to the
> public internet there?
>
> Any suggestions for Open Source Puppet as well?
>
> Thanks
> Matthias
>
>
> david.sa...@puppet.com schrieb am Donnerstag, 20. Oktober 2022 um
> 17:29:59 UTC+2:
>
>> Our support for TLS termination is messy and you need to use a reverse
>> proxy in front of PE, We have a couple of Patterns surrounding multi
>> region solutions using proxies and compilers which may be helpful
>>
>>
>> https://puppet.com/docs/pe/2021.7/installing_compilers.html#multi-region-load-balancing
>> AWS Multi-region architectures for Puppet Enterprise
>> <https://puppet.com/docs/patterns-and-tactics/latest/reference-architectures/aws-reference-architecture-guide.html#in-region-proxies-variation>
>> PE Multi-region reference architectures (puppet.com)
>> <https://puppet.com/docs/patterns-and-tactics/latest/reference-architectures/pe-multi-region-reference-architectures.html#in-region-proxies-variation>
>>
>> On Wednesday, October 19, 2022 at 5:49:29 PM UTC+1 m...@webfactory.de
>> wrote:
>>
>>> Dear Puppet Users,
>>>
>>> until now, I have been using Puppet in firewalled environments only,
>>> where agents were on the same trusted network as the server or connected
>>> through VPN tunnels.
>>>
>>> Now there seem to be some good reaons for switching to a "perimeterless
>>> security" approach, which would mean to drop the VPN and put the Puppet
>>> Server on the public internet. In my special case, I could not even do any
>>> IP-based filtering.
>>>
>>> I could not really find any good material or recommendations on this. Is
>>> this a discouraged/dangerous practice, or is it more common than I was
>>> assuming?
>>>
>>> The basic approach of mutual, certificate-based authentication in Puppet
>>> seems to perfectly support this scenario, and comes with encryption built
>>> in. And yes, of course I would _not_ enable certificate autosigning.
>>>
>>> Are there other risks to be aware of? Any recommendations on hardening
>>> the setup?
>>>
>>> Maybe I am a bit sceptical because a component like Puppet Server has
>>> not received the scrutinity as e. g. an Apache or Ngnix webserver regarding
>>> potential attack surfaces and security issues. The sensitive information a
>>> compromised Puppet Server might leak cannot be ignored.
>>>
>>> Would it make sense to place the Puppet Server behind a major
>>> webserver/proxy (Apache, Varnish etc.)? Would it be possible to reject all
>>> connections that do not provide client certificates and use some
>>> out-of-band process for signing new client certs?
>>>
>>> Thank you for all suggestions!
>>> -mp.
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/2d0dbc52-11c9-4c12-9887-db2c4340be17n%40googlegroups.com.
