By Binh 
In the previous blog, Setup Puppet 8 on Ubuntu 24.04 – Configuration Management for a scaling enterprise, we know that when a Puppet Agent start for the first time, it sends a certificate signing request (CSR) to the Puppet Server (known as Puppet Master in the old version). We then have to sign this request manually by running, e.g. puppetserver ca sign --certname node-name.example.com.
The manual signing is designed by default in Puppet for security reason, it means that these CSRs must be signed by an admin user, which requires them to review the node manually to identify whether the node is legit. However, on a scaling system, especially in cloud environment, where we usually, rebuild or destroy a node frequently, the manual signing processs might not be ideal in this case.
Autosigning Types
Then Puppet offers autosigning feature to speed up the processs of launching new agent nodes. And basically, we have three main types:
- Naïve autosigning: not recommended for use in production, just use with test purpose.
- Basic Autosigning: As it’s called, we simply add the name or certname of an agent node to the
$confdir/autosign.conffile. Puppet Server signs all CSRs from nodes defined in this list. This method is considered insecure. That’s because if we set a wide range of certnames to be autosigned, for example,*.example.com, attackers can guess the domain name and enter a random node name, e.g.random-1.example.comto obtain a signed request and easily retrieve information from the catalog’s configuration. - Policy-based Autosigning: The Puppet CA runs a custom executable script each time it receives a new CSR, you can write the script in any programming language. The idea of the script is to examine the certname (FQDN) and the PEM-encoded CSR on stdin stream, and tells Puppet whether to accept the CSR (exit status 0) or to reject it (return non-zero exit status). The certname is passed as an argument to the script. The CSR contains embedded additional information, which we provide when provisioning the node.
Creating a policy-based autosigning system can be complicated, depending on the level of security you need. In this blog, I want to try to show a simple example so that you can develop more from that. The main idea is to show you how it works.
Prerequisites
- An Ubuntu 24.04 server with Puppet 8 ( Puppet Server) installed. If you haven’t done it yet, please look at the link above.
- Another 2 x Ubuntu 24.04 servers with puppet-agent (openvox-agent) installed, just for autosigning demo. I have 2 servers:
consul-01andconsul-02in this case.
To implement a policy-based autosigning, we care mainly about two parts:
- The CSR data: this is what we defined in
$confdir/csr_attributes.yamlfile on agents. Normally contains one or both of the following keys:custom_attributes: known as transient CSR data, basically, it means CA use it to decide whether to sign the request or not, and can’t be used by anything later.extension_requests:is permanent certificate data, not only used to decide whether to sign the request, but also is transferred as extensions to the final certificate. They persist as trusted, immutable data; we can later retrieve this piece of data through Facts.
- The signing policy script: this is the executable script we write, which complies with the suggested Puppet’s Policy executable API. And it stays on Puppet Server.
Use custom_attributes
Configuring on Puppet Server
We work with the signing policy script first.
On Puppet Server, we will create a basic Bash script (you can use your preferred language).
Run sudo nano /usr/local/bin/check_csr.sh and add the content below:
#!/bin/bash
# Define a shared PASSWORD that CA uses to compare with a password sent by agent
PASSWORD="Your-challenge-password"
# Capture the certname (FQDN) passed as argument from the request.
# E.g. agent-01.example.com
CERT_NAME=$1
# Open incoming CSR sent from the agent, grep the password supplied
# and capture its value
AGENT_PASSWORD=$(openssl req -noout -text -in /etc/puppetlabs/puppet/ssl/ca/requests/${CERT_NAME}.pem | grep 'challengePassword' | awk '{print substr($2,2)}')
# Compare both the shared password with the supplied password
if [ "$AGENT_PASSWORD" == "$PASSWORD" ] ; then
STATUS=0
echo ">>> Approved agent: ${CERT_NAME}"
else
STATUS=1
echo ">>> ALERT! - ${CERT_NAME}'s password is incorrect or missing"
fi
exit $STATUS
Press Ctrl + O and press Enter to save the content. Then press Ctrl + X to exit.
Grant executable permission to the file, run:
sudo chmod +x /usr/local/bin/check_csr.sh
You can store the script in any directory you want.
Enabling autosign
Still on Puppet Server, we need to enable autosign under [server] section in /etc/puppetlabs/puppet/puppet.conf, open the file and add:
[server]
server = puppet-master.srv.local
# Other configurations...
# Specify the path of the executable script.
# Change the path according to where you store the script.
autosign = /usr/local/bin/check_csr.sh
Reload Puppetserver service:
sudo systemctl reload puppetserver.service
Configuring on consul-01
After you provisioned a node and installed the puppet-agent package (or openvox-agent if you followed my previous blog), my Puppet Agent in this demo has a certname of consul-01.srv.local.
If you haven’t run puppet agent -t to send a CSR to the Puppet Server, then we can create a csr_attributes.yaml file, which controls what data we can add additionally to the CSR that the Puppet Agent will generate.
Case 1: Test the incorrect password
We’re going to append an attribute called challengePassword to the csr_attributes.yaml file, and we assign an incorrect password to test the failure case first:
Run sudo nano /etc/puppetlabs/puppet/csr_attributes.yaml and add the following content:
custom_attributes:
challengePassword: "Your-incorrect-password"Press Ctrl + O and press Enter to save the content. Then press Ctrl + X to exit.
We have to follow the recommended OIDs for attributes, challengePassword attribute is an example of a valid object identifier (OID). We use it as a pre-shared key, which is the shared password we defined in this demo.
If you have run puppet agent -t, and sent the CSR already without adding the csr_attributes.yaml file, we can force the Puppet Agent to generate new certificates by deleting the existing ones from the agent, simply run:
sudo rm -rf /etc/puppetlabs/puppet/ssl/
And follow the steps above to create csr_attributes.yaml file.
Go to the Puppet server, run:
sudo /opt/puppetlabs/bin/puppetserver ca clean --certname <your-agent-certname>
Once done, go back to the agent and run:
sudo /opt/puppetlabs/bin/puppet agent -t
Output:
You will see the generated CSR is not signed. Because we passed the incorrect password.
Go to the Puppet Server, we examine the CSR of consul-01 agent, the incoming CSRs are placed in the directory /etc/puppetlabs/puppet/ssl/ca/requests.
We use OpenSSL to dump the CSR in pem format to text format, run:
# Change "consul-01.srv.local" to your agent's certname
openssl req -noout -text -in /etc/puppetlabs/puppet/ssl/ca/requests/consul-01.srv.local.pem
Output:
Certificate Request:
Data:
Version: 1 (0x0)
Subject: CN = consul-01.srv.local
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
00:ae:9b:e1:f3:2c:52:eb:1b:c1:b5:52:29:66:5e:
fe:bb:7d:51:cd:9f:95:97:fa:ba:a0:21:3e:e0:51:
1e:85:9e:32:11:b3:f3:ff:c4:b1:92:f3:c1:5e:c9:
e9:e2:8a:25:70:ed:65:8e:eb:b9:61:95:a2:76:ba:
a4:df:09:29:2b:10:28:70:fb:be:5a:03:f4:82:b4:
5e:83:28:98:2e:a2:8d:fb:50:b8:80:13:eb:9f:7e:
36:36:a9:e4:b9:cf:e0:ce:32:58:07:91:61:4b:4f:
03:bf:57:9b:0c:ed:0b:7a:d0:6f:6a:58:7d:ee:60:
52:2a:8f:18:b9:10:e8:83:36:be:e3:19:c7:d3:23:
3d:8e:a9:ca:67:3f:ba:94:ae:42:bd:18:af:43:a2:
a3:af:78:81:a8:1a:73:47:8f:e4:85:03:b9:8c:e0:
b9:8b:18:99:cc:66:a9:00:a7:a4:ef:9b:dc:ad:d9:
f5:b8:07:a6:55:e4:ba:5f:e4:53:9c:4a:78:63:fb:
51:10:7e:1d:98:15:24:08:db:7e:23:b0:93:15:ef:
cc:e5:c1:d8:d7:ed:eb:86:6c:29:3a:ea:5a:db:74:
54:cf:d1:7b:b3:d2:db:cd:36:c0:0c:42:f4:64:ed:
bf:7e:cd:bf:98:45:9e:c0:fd:b6:b4:8b:16:af:77:
75:f8:35:35:b3:69:c6:b1:55:78:6d:8c:22:96:dd:
da:ff:b0:62:95:ae:4d:80:32:47:29:1c:71:65:c7:
85:d2:26:00:0a:85:b1:7e:b0:15:e8:c6:a9:a0:4b:
14:93:6b:2b:ac:cc:fd:f7:ca:1d:4d:b8:2f:85:55:
16:42:34:2e:ce:c3:34:2e:4b:a2:c4:95:50:91:59:
d2:7e:bd:10:e6:62:00:0e:f5:49:e6:f9:13:7a:82:
9f:a2:b2:45:d9:66:b2:9d:38:2f:8d:17:d5:73:8d:
ec:39:80:18:3a:d6:90:28:5c:7e:7d:cf:a7:5d:0b:
b8:03:8a:35:9c:ce:8c:6f:3a:4b:08:79:99:c6:31:
84:79:f7:7b:27:00:7d:be:9f:91:3e:28:43:9e:d1:
c3:5e:f4:d5:4f:e5:21:de:bf:6d:f7:da:46:a5:91:
72:4f:eb:00:4c:a9:a4:23:fa:5b:38:d7:83:81:97:
24:28:75:28:35:2e:cf:a8:ed:1c:47:a7:2a:8d:a3:
e8:47:db:f6:14:9d:e1:71:86:bd:83:b2:1c:df:7c:
91:d8:f7:29:0a:4b:e2:12:c2:b0:c9:f7:c7:ee:2a:
a8:0b:8d:aa:d3:09:d8:de:dd:cd:d0:71:13:11:16:
f6:64:f2:04:55:92:f5:02:d9:d6:24:5b:e2:43:3a:
a2:8f:1f
Exponent: 65537 (0x10001)
Attributes:
1.3.6.1.4.1.34380.1.3.2 :true
challengePassword :Your-incorrect-password
Requested Extensions:
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
46:78:48:5a:ca:c2:88:76:55:f3:97:a7:6d:64:ed:93:54:0e:
d0:57:48:7e:74:c3:5f:26:4c:28:6e:25:ed:27:eb:86:cd:65:
6f:18:08:93:09:34:32:6e:91:9b:44:ff:bf:22:8f:2f:62:5d:
14:d2:bd:55:85:a6:18:10:18:82:96:43:04:be:dd:14:78:7a:
e1:43:75:b9:0a:83:e5:d0:e8:0c:a5:1f:bd:7d:8b:3e:55:39:
0e:dc:39:91:98:a1:83:48:14:89:3c:9a:2b:d8:2d:04:1f:68:
46:85:0e:22:95:60:5e:57:d1:a8:79:4e:e5:0e:25:09:a8:44:
09:0b:1f:cc:5d:ee:83:0b:bc:e9:14:dd:db:b8:8c:66:c1:3d:
79:23:20:97:5c:42:17:d7:71:b4:f1:03:d4:1f:ba:55:31:e7:
d2:5c:48:8e:5a:d3:83:33:04:df:b4:06:03:b2:07:d8:bc:5a:
0b:29:10:06:a5:13:b7:67:83:63:21:fc:1f:51:fc:3c:a5:5b:
fa:3b:9a:ba:c2:6c:0c:43:a0:95:71:f0:8a:98:b2:13:b7:78:
4c:05:36:f5:8b:2e:13:c4:ad:ea:dd:5d:bf:8d:6b:17:84:31:
3f:71:a2:79:52:a1:3a:02:7e:a7:4d:11:7b:ec:b8:da:7a:a7:
f2:c9:6c:bf:5f:89:03:1b:33:d6:25:cc:95:12:09:a3:f7:42:
24:ec:28:b6:b6:cd:9a:07:d2:38:c7:e1:ff:fb:d4:17:83:ec:
8a:60:4d:2b:75:45:12:10:ce:3d:f9:d2:0f:9f:56:98:21:d4:
ac:f2:db:ff:dd:01:03:93:aa:97:c4:e9:9e:e7:1a:c3:3f:68:
96:ba:f5:4e:df:2f:7d:09:6d:9a:5d:42:60:77:8b:45:5e:e8:
e1:36:de:fd:a9:c8:ca:96:25:86:2f:73:5b:67:1e:8b:3c:a7:
24:7b:ee:59:a9:7d:e8:37:c3:7e:b7:e2:29:d0:fd:a8:1e:8d:
2d:ab:1a:85:fd:06:d6:2b:a6:99:34:ab:c6:19:bf:aa:35:1d:
15:e0:d0:c7:78:84:47:14:c9:47:56:71:39:c5:fe:31:d2:51:
9f:8c:ae:6b:eb:4c:78:d1:95:33:67:a0:c6:1b:6a:23:db:bc:
17:f2:61:42:61:ee:e0:c2:14:f9:df:5d:af:16:3a:28:4c:1c:
e2:21:92:32:c3:6c:b4:49:fe:56:ac:15:2e:03:4a:f7:71:63:
67:ee:6f:43:34:d2:0f:05:90:d9:fa:59:e0:6c:d2:fd:38:a3:
d6:3b:31:f7:ca:62:02:df:b2:02:9f:89:0e:91:c8:3c:e5:94:
9d:02:78:8d:94:2e:d9:dbUse our script to check by running
/usr/local/bin/check_csr.sh consul-01.srv.local
Output:
>>> ALERT! - consul-01.srv.local's password is incorrect or missingCase 2: Test the correct password
Before we continue, we need to clean up the CSR of consul-01 containing an incorrect password on Puppet Server.
On Puppet server, run:
sudo /opt/puppetlabs/bin/puppetserver ca clean --certname consul-01.srv.local
To confirm, we can check it by running ls -l /etc/puppetlabs/puppet/ssl/ca/requests/ to make sure the consul-01.srv.local.pem is deleted.
Then, go back to the Puppet Agent server (mine is consul-01) again, we delete the old generated certs:
sudo rm -rf /etc/puppetlabs/puppet/ssl/
Update the /etc/puppetlabs/puppet/csr_attributes.yaml with correct password, for example:
custom_attributes:
challengePassword: "Your-challenge-password"And re-run the command below to send a new request again to the Puppet Server:
sudo /opt/puppetlabs/bin/puppet agent -t --waitforcert 10
Output:
We can see now that the CSR is signed already, and it starts applying the configuration from the production environment.
The /etc/puppetlabs/puppet/ssl/ca/requests/consul-01.srv.local.pem file contains the correct challengePassword, and the Puppet CA signed it automatically. Once it’s signed, the file is removed automatically, and you won’t be able to see it.
NOTED:
The main concern of this autosigning method is that we have to set up a /etc/puppetlabs/puppet/csr_attributes.yaml with a supplied password. In this demo, we manually create it, but in a real case, it’s better to use a provisioning tool to automate this part for us. For example, in the AWS environment, you can use CloudFormation or Terraform to automatically create this file with its parameters when provisioning an instance.
I’m running a home lab where I provision this node with Vagrant, which has a script to create this file automatically every time I launch it. This is out of scope for the blog, so I just share what it looks like in a real case.
Use extension_requests
In the example above, we use custom_attributes for autosigning. To increase security, we can also add extension_requests to provide more unique identity information that builds trust for the node.
Similar to the challengePassword attribute, each attribute we use under extension_requests must comply with the OID, and it must follow one of the formats:
ppRegCertExt(1.3.6.1.4.1.34380.1.1)ppPrivCertExt(1.3.6.1.4.1.34380.1.2)ppAuthCertExt(1.3.6.1.4.1.34380.1.3)
For ppRegCertExt and ppAuthCertExt, you can have a look at Puppet-specific registered IDs to know more about meaning of each OID’s name. The ppPrivCertExt is custom fields that we define.
In this part, we will use ppRegCertExt as an example here.
Configuring on consul-02 server:
I provisioned another server named consul-02.srv.local, and of course, I’ve installed openvox-agent package as what we did for consul-01.
Create the /etc/puppetlabs/puppet/csr_attributes.yaml on consul-02 with content:
custom_attributes:
challengePassword: "Your-challenge-password"
extension_requests:
pp_uuid: "324a9b45-6463-4701-b45e-4b5ae9169b1c"
pp_service: "consul"
For OID in the csr_attributes.yaml file, we can specify either Numeric ID or its short_name. In the config, I’m using short_name:
pp_uuid: it is Puppet Node UUID. Numeric ID –1.3.6.1.4.1.34380.1.1.1pp_service: is the Puppet node service name. Numeric ID –1.3.6.1.4.1.34380.1.1.9.
This is a tricky part, as when you provision a node, you will need a way to identify the Node UUID and add its value to two places. One is the csr_attributes.yaml on the agent and the second is on the Puppet Server so that it can use it to compare with the UUID on CSR data sent by the agent. Actually, we have to do this for all OIDs. The main idea is that we have to provide data to Puppet CA and Agent to compare. I would say it’s best that we know a programming language to automate this part for us.
And again, this is just an example, depending on the level of security you want to apply to your system, you would select appropriate OIDs that match your requirements.
For pp_uuid
On Virtualbox:
I’m using Virtualbox on a local machine, and I can run:
VBoxManage.exe list vms
Output:
"consul-01" {0cb974a4-955f-449d-8d0c-ac447fac702e}
"consul-02" {324a9b45-6463-4701-b45e-4b5ae9169b1c}Copy the corresponding UUID and add it to the key pp_uuid. Here is 324a9b45-6463-4701-b45e-4b5ae9169b1c.
On EC2:
Can run:
sudo dmidecode --string system-uuid
For other platforms, please search for it on Google/ChatGPT or anything similar to find out more.
For pp_service:
It depends on how you name your service; I just named it “consul” in this case.
At this step, DO NOT run sudo /opt/puppetlabs/bin/puppet agent -t yet. We need to provide a metadata of the provisioned node to the Puppet Server so that it has the node's information.Configuring on Puppet Server (puppet-master)
Create a folder to store the node’s metadata, run:
sudo mkdir /etc/puppetlabs/puppet/nodes_metadata
Create a node’s metadata file for consul-02
Run nano /etc/puppetlabs/puppet/nodes_metadata/consul-02.srv.local.metadata , and add:
# Change UUID to your VM's UUID
node_uuid="324a9b45-6463-4701-b45e-4b5ae9169b1c"
service_name="consul"Press Ctrl + O and press Enter to save the content. Then press Ctrl + X to exit.
Grant permission to the puppet user to access /etc/puppetlabs/puppet/nodes_metadata:
sudo chown -R puppet:puppet /etc/puppetlabs/puppet/nodes_metadata
Now, we need to update the /usr/local/bin/check_csr.sh to let it get the node_uuid and service_name data from the CSR.
#!/bin/bash
# Define a shared PASSWORD that CA uses to compare with a password sent by agent
PASSWORD="Your-challenge-password"
# Capture the certname (FQDN) passed as argument from the request. E.g. agent-01.example.com
CERT_NAME=$1
METADATA_DIR="/etc/puppetlabs/puppet/nodes_metadata"
# Capture NODE_UUID's value
NODE_UUID=$(cat ${METADATA_DIR}/${CERT_NAME}.metadata | grep node_uuid | awk -F'"' '/node_uuid/ {print $2}')
# Capture SERVICE_NAME's value
SERVICE_NAME=$(cat ${METADATA_DIR}/${CERT_NAME}.metadata | grep service_name | awk -F'"' '/service_name/ {print $2}')
CSR_REQUEST_DIR="/etc/puppetlabs/puppet/ssl/ca/requests"
# Open CSR sent from the agent:
# 1. grep the password supplied, and capture its value
AGENT_PASSWORD=$(openssl req -noout -text -in ${CSR_REQUEST_DIR}/${CERT_NAME}.pem | grep 'challengePassword' | awk '{print substr($2,2)}')
# 2. grep the node_uuid supplied, and capture its value.
AGENT_NODE_UUID=$(openssl req -noout -text -in ${CSR_REQUEST_DIR}/${CERT_NAME}.pem | grep -A1 1.3.6.1.4.1.34380.1.1.1 | awk 'FNR==2{print substr($1,3)}')
# 3. grep the service_name supplied, and capture its value
AGENT_SERVICE_NAME=$(openssl req -noout -text -in ${CSR_REQUEST_DIR}/${CERT_NAME}.pem | grep -A1 1.3.6.1.4.1.34380.1.1.9 | awk 'FNR==2{print substr($1,3)}')
# Compare data on puppet-master vs data provided by agent. Must match 3 conditions to autosign:
if [ "$AGENT_PASSWORD" == "$PASSWORD" ] && [ "$AGENT_NODE_UUID" == "$NODE_UUID" ] && [ "$AGENT_SERVICE_NAME" == "$SERVICE_NAME" ]; then
STATUS=0
echo "Approved agent: ${CERT_NAME}"
else
STATUS=1
echo "*!ALERT!* ${CERT_NAME}' doesn't meet requirements"
fi
exit $STATUS
Press Ctrl + O and press Enter to save the content. Then press Ctrl + X to exit.
NOTED: In the script, we have to specify
Numeric IDof OID instead ofshort_name. OpenSSL command can’t understand theshort_namepre-defined by Puppet, so it can’t read it properly.
Now, go back to consul-02 server, and run:
sudo /opt/puppetlabs/bin/puppet agent -t --waitforcert 10
Output:
The consul-02’s CSR is signed automatically.
At the time of running the command above, if I quickly switch to puppet-master (otherwise, the file is immediately removed after being signed), my CSR request from consul-02 will have attributes that look like this:
Certificate Request:
Data:
Version: 1 (0x0)
Subject: CN = consul-02.srv.local
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
00:9f:f1:8a:57:a4:c5:57:fb:b3:f8:66:f4:2d:61:
4a:6f:2f:ec:d7:f1:8b:78:aa:93:a5:0a:c0:16:02:
.....
Exponent: 65537 (0x10001)
Attributes:
1.3.6.1.4.1.34380.1.3.2 :true
challengePassword :Your-challenge-password
Requested Extensions:
1.3.6.1.4.1.34380.1.1.1:
.$324a9b45-6463-4701-b45e-4b5ae9169b1c
1.3.6.1.4.1.34380.1.1.9:
..consul
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
18:a6:58:ab:84:01:49:f6:6f:e9:e2:83:fc:4c:1e:1d:ed:e9:
26:44:c1:3a:8a:a5:ba:c6:f6:ee:cf:e0:d3:03:fa:93:61:c8:
....As I mentioned above, the extension_requests is treated as permanent data. We can check it by running:
# Change the certname to your certname
/opt/puppetlabs/puppet/bin/openssl x509 -noout -text -in $(/opt/puppetlabs/bin/puppet config print signeddir)/consul-02.srv.local.pem
Output:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 5 (0x5)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = Puppet CA: puppet-master.srv.local
...
# other data
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:consul-02.srv.local
Netscape Comment:
Puppet Server Internal Certificate
X509v3 Authority Key Identifier:
keyid:4D:5C:73:8D:D1:DE:C1:86:38:DC:8C:45:9E:E1:70:96:E5:76:2D:9A
DirName:/CN=Puppet Root CA: ab07eb0dba607a
serial:02
X509v3 Subject Key Identifier:
A9:9E:1D:EC:08:82:11:B4:F3:EB:9F:B6:FB:D4:F7:92:1D:7B:3C:EF
1.3.6.1.4.1.34380.1.1.1:
.$324a9b45-6463-4701-b45e-4b5ae9169b1c
1.3.6.1.4.1.34380.1.1.9:
..consul
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Extended Key Usage: critical
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
70:a1:7e:e6:a5:a0:f3:0a:f2:7e:43:c1:d8:6e:38:49:73:31:
b7:b7:2f:43:47:67:4e:b3:0b:20:a4:47:eb:41:d5:8c:63:7e:
24:a1:32:ee:93:66:ba:f2:dd:10:7d:87:cc:b3:2f:4e:dd:e1:
....Ok, that’s all we need for a basic policy-based autosigning. I know it still requires other tasks to automate this signing process completely, but ideally, this is how policy-based autosigning works. We might need to design carefully for this implementation.
My thoughts
In the demo above, we hard-coded the password in the /usr/local/bin/check_csr.sh file. In reality, we probably don’t want to hard-code it in that way. There are many ways to keep it more secure; I can name a few here:
- Encrypt the password and store it in a database. When
check_csr.shruns, it queries the password from the database instead. - Use a private/public RSA key pair to encrypt and decrypt the password when
check_csr.shruns, and then we just set the encrypted password in the script. - Or basically, don’t use the password, and use other attributes to verify instead.
Also, we can consider implementing an API system that stores the nodes’ metadata, and check_csr.sh just sends the certname to the API system to verify whether the node is valid. This requires a higher programming level and is more secure for the system.
Share this:
Discover more from Turn DevOps Easier
Subscribe to get the latest posts sent to your email.