Smartproxy PuppetCA never triggered

Support
1

Foreman 1.15.0 here.

My Foreman environment is set up to manage Puppet host certificates:

<https://lh3.googleusercontent.com/-nK1YKhByNcM/WTptQFtRWbI/AAAAAAAAAEI/N2XUhWrJwww7VBybVJkjuwY9S9BETYRugCLcB/s1600/Settings%2B-%2BGoogle%2BChrome_024.png>

I have a perfectly operational PuppetCA proxy. I can manually
view/sign/revoke/autosign certificates no problem:

<https://lh3.googleusercontent.com/-Qi-9skJ62kM/WTpt1M-yOfI/AAAAAAAAAEQ/D4jXCzrynnk-jiijF9vO_WYuWxzbA4kTwCLcB/s1600/Smart%2BProxy%3A%2BPuppetCA%2B-%2BGoogle%2BChrome_025.png>

PuppetCA proxy is assigned to organization and location (no screenshots
here, trust me :wink: ).

My hostgroup is set up to use the above PuppetCA smartproxy to manage the
certificates:
<https://lh3.googleusercontent.com/-_HyTRgoHFFI/WTpuJt9HITI/AAAAAAAAAEU/15rhZ9WCTxU_HpCZ8OHjZ_7upN0WnWojgCLcB/s1600/Edit%2BGT%2B-%2BGoogle%2BChrome_026.png>

However, I still need to sign CSRs manually. Looks like the PuppetCA proxy
autosign POST endpoint does not get triggered during the orchestration
process.
This applies to all hosts: manually created-provisioned and
discovered-autoprovisioned.

WIth the DEBUG sql turned on, I get nothing like 'puppetca' or 'puppet ca'
when I hit 'build host' or 'auto-provision'.
However, in the PuppetCA proxy logs I can see some 404s:
–> when the foreman_url("built") is reached: https://pastebin.com/Y0KgRkje
–> when deleting the host: https://pastebin.com/ebJzM68c
This makes perfect sense, as the autosign was never there in the first
place.
Once again, I can do anything I like from Infrastructure->Smart
Proxies->PuppetCA page (so the ACL/permissions are OK).

I use the discovery image and a custom initrd provisioning. To break the
custom initrd PXE boot loop, the host curls the foreman_url("built")
(passed as kernel parameter and called from initrd scripting).

Now the problems I see:
–> according to klaas' words on IRC, reaching the foreman_url("built")
shall remove hosts fqdn from the autosign.conf file; the host never had a
chance to run puppet yet (needs to boot from hd); this probably breaks
most scenarios that include Foreman Discovery Plugin
–> anyway, as stated above, I cannot see autosign.conf edited nor the
PuppetCA proxy POST called when hitting 'build host' or 'auto-provision'
–> probably can work around with Foreman Hooks, but seems like reinventing
the wheel.

Thoughts on this?
Missing POST looks like a minor code issue. But the Discovery Plugin -
PuppetCA - foreman_url("built") relation issue goes deeper. Maybe I should
use other API endpoint?
Please share your view on this. Thank you.

2

Heya,

> However, I still need to sign CSRs manually. Looks like the PuppetCA
> proxy autosign POST endpoint does not get triggered during the
> orchestration process.
> This applies to all hosts: manually created-provisioned and
> discovered-autoprovisioned.
>
> WIth the DEBUG sql turned on, I get nothing like 'puppetca' or
> 'puppet ca' when I hit 'build host' or 'auto-provision'.
> However, in the PuppetCA proxy logs I can see some 404s:
> --> when the foreman_url("built") is reached: https://pastebin.com/Y0
> KgRkje
> --> when deleting the host: https://pastebin.com/ebJzM68c
> This makes perfect sense, as the autosign was never there in the
> first place.
> Once again, I can do anything I like from Infrastructure->Smart
> Proxies->PuppetCA page (so the ACL/permissions are OK).

This is somewhat expected (with a catch) - let me fill in a little
history :slight_smile:

The autosign is viewed as a security hole - during the time which the
entry is present in the file any host could claim to be the newly
building machine and grab the cert. So, to minimize the risk, one has
to minimize the time it's there.

Hosts could be put into build mode, and then not rebooted for some
time, so instead we choose to make the call to the proxy for autosign
at the point when the the "provision" template is requested (this is
usally the second template, called from the PXE template written to the
TFTP server). So the time line is:

  • Host is set for build
  • Host is rebooted
  • Host TFTPs
  • Host loads Anaconda / Preseed
  • Host downloads the "provision" template from Foreman
  • Autosign is set

At this point the window for signing is now open.

> I use the discovery image and a custom initrd provisioning. To break
> the custom initrd PXE boot loop, the host curls the
> foreman_url("built") (passed as kernel parameter and called from
> initrd scripting).

Here's the catch I mentioned - you say "custom" so I'm not sure of the
details, but if you're not calling the "provision" template
(Kickstart/Preseed etc) then I'd expect this result, since that's the
trigger.

> Now the problems I see:
> --> according to klaas' words on IRC, reaching the
> foreman_url("built") shall remove hosts fqdn from the autosign.conf
> file; the host never had a chance to run puppet yet (needs to boot
> from hd);

Actually our default templates contain a call to Puppet agent like
this:

puppet agent <other options> --onetime --tags no_such_tag

The "onetime" flag means it doesn't try to start a daemon (which would
likely fail in an installer env) and the "tags" mean no actual puppet
code is executed (which would probably also fail) - but it does count
as a proper Puppet run, and retrieves the cert.

This is usually the very last line before calling "built" and wiping
out the autosign.

> this probably breaks most scenarios that include Foreman Discovery
> Plugin
> --> anyway, as stated above, I cannot see autosign.conf edited nor
> the PuppetCA proxy POST called when hitting 'build host' or 'auto-
> provision'
> --> probably can work around with Foreman Hooks, but seems like
> reinventing the wheel.

Discovery shouldn't be impacted - again you mention a custom workflow,
so perhaps you have other ideas, but the usual workflow for Discovery
is to boot into Kickstart / Pressed which will then trigger the
autosign entry (from the "provision" call), and get the cert at the
end, just as normal.

My gut feeling here (based on how you say you're doing different
things) is that we have a mismatch on expectations of how things should
work - hopefully this clears up how we expect things to work by
default. I'd love to hear more about how you're using it though - feel
free to grab me on IRC if you want to go over it in realtime :slight_smile:

Cheers
Greg

··· On Fri, 2017-06-09 at 04:25 -0700, Garreat wrote: -- IRC / Twitter: gwmngilfen
3

I have successfully tested this.
Calling curl foreman_url('provision') returns "No provisioning template
found for host xxxxx".
But the autosign entry still gets created.

That's good, opens options :).