Update multimaster_pki.rst #61962
Update multimaster_pki.rst #61962
Conversation
|
Hi there! Welcome to the Salt Community! Thank you for making your first contribution. We have a lengthy process for issues and PRs. Someone from the Core Team will follow up as soon as possible. In the meantime, here’s some information that may help as you continue your Salt journey.
There are lots of ways to get involved in our community. Every month, there are around a dozen opportunities to meet with other contributors and the Salt Core team and collaborate in real time. The best way to keep track is by subscribing to the Salt Community Events Calendar. |
| key-pair on a different system than the actual salt-master and create the public | ||
| keys signature there. Probably on a system with more restrictive firewall rules, | ||
| without internet access, less users, etc. | ||
| This process turns each master into a "signing" master server that helps reduce overhead for auth-requests coming from minions. |
There was a problem hiding this comment.
so, while i agree this isn't about creating a separate signing master. as the original text wanted to allude to. I don't think this helps reduce auth requests in the slightest. and in fact requires more processing for auth keys. but it does add a layer of security.
Previous verbiage gave the impression that a separate "signing" server can be used to prevent the copying of private keys (ie. master.pem) across the network. The problem is that the process to generate a signature file requires both the master.pem (from the original master) and the master_sign.pem (from the signing master) to be on the same box. This would require either copying the appropriate pem file from one master to another. Unfortunately, there is no current way around copying the pem files if you are trying to implement a separate master signing server. This process turns an existing master into a signing server to reduce overhead of auth-requests coming from minions attached to it.
Previous verbiage gave the impression that a separate "signing" server can be used to prevent the copying of private keys (ie. master.pem) across the network. The problem is that the process to generate a signature file requires both the master.pem (from the original master) and the master_sign.pem (from the signing master) to be on the same box. This would require either copying the appropriate pem file from one master to another. Unfortunately, there is no current way around copying the pem files if you are trying to implement a separate master signing server.
This process turns an existing master into a signing server to reduce overhead of auth-requests coming from minions attached to it.
What does this PR do?
Corrects the inference that a separate signing master server prevents the copying of private keys across the network.