Certificate signing of puppet node | Manual Signing | Human security options

[bitvijays]

Dear Puppet Team/ Community,

Hope you are doing well. Thank you for your support.

We understand that there are two different ways of signing the certificate

1. [Manually] CSRs must be manually signed by an admin user, using the puppetserver ca command
2. [Automatic] Autosigning certificate requests - autosigning bring security issues.

We wanted to understand the options available in a particular scenario where we are using manual signing, however

There could be a scenario where

• an attacker has knowledge of the puppet server IP Address, node-naming convention and has set up a similar node-name e.g., node-005.example.local similar to the one already present in the organization (let's say node-001/2/3/4.example.local).
• The IT administrator would see a signing request from node-005,example.local.
• Now, generally the IT administrator knows which node has been provisioned and they would sign that node request. However, sometimes it might happen that they haven't provisioned a node and sees a CSR with a similar node-name.
• In such scenario, they can possibly make a mistake to sign it.

We were wondering if there's a way to have a double check to stop occurring the above scenario? Maybe, there's a way to couple it with puppet facts which could be presented to the puppet server and could be added to improve security?

Yours Sincerely,
bitvijays

[bitvijays]

In Slack Argon Wade suggested

Trusted facts, which become part of the node certificate which can then be referenced in Puppet code. Bear in mind, if an attacker has knowledge of trusted facts and expected values, then they become less useful as a security mitigation in the scenario you provide. At that point though, you have bigger fish to fry.

Depending upon your system deployment process, I suppose some two-factor/key-based script which connects to something else that verifies the node’s authenticity could be included just before the puppet agent gets installed that injects a token into the node’s CSR (trusted fact), and that trusted fact could then become a Puppet check that if fails lights up your SIEM like a good fireworks show.

[bitvijays]

In Slack Matt suggested

I think if someone has the ability to deploy new infrastructure in your environment with your administrative and ops folks being completely in the dark....I think puppet signing a cert is the least of your concerns, no offense.

[bitvijays]

In slack, Vijay replied to Argon Thank you for your suggestion. By any chance, have you come across someone or some blog where the above mechanism has been deployed? Mainly, because we understand the concept, however would like to deploy and implement it. @ Matt I do agree with that. However, I have been request to see if there's a double verification possible to avoid the mistake.

[bitvijays]

Argon replied "I have not. And be sure, though such an approach would add a layer of security, it isn’t something I’d rely on if you want to be absolutely certain. Not to mention the level of effort that would go into something so home-grown...

Realistically, if you’re at a point where an unauthorized actor is creating nodes, that node receiving a catalog from Puppet is so far down the list of concerns as to be moot."

[bitvijays]

Matt replied "So i'll give my two cents here:

I am a security professional by trade, it's pretty much what I've done my entire IT career. While I empathize with your position to "find a solution" because you're being asked/forced to, this is one of those "security for the sake of security" type things. As far as I know nothing in Puppet supports this natively so you'd have to build something yourself. Guess what? Terrible idea imho. Home-grown solutions are only as good as they are maintained which is seldom. I would go back to whoever is making this request to you and understand what threat they're trying to address by implementing some secondary check like this. What scenario are you envisioning in your head? Chances is are, it's based on fiction and not fact in my experience.

If someone has the level of access within your network to deploy infrastructure and administrative access to your puppet server to sign the cert.... it's game over for you, you understand that right? A secondary check isn't going to resolve that fact because as a malicious actor, why am I going to bother deploying a new node? What do I gain there? Nothing. What am I going to do instead? Write a puppet manifest and backdoor all your servers.
Not trying to give you a hard time or anything but I just don't see the point in something like this, it's not helpful or beneficial to your security posture in any measurable way and create additional headaches and overhead that benefits no one"

[bitvijays]

Have documented the conversation here for the community records. As on the slack, this could be difficult to find.