Puppet节点无法加入AWS上PE主节点，报/puppet-ca/v1/certificate/ca禁止请求错误

Let's work through this issue step by step—since you've already ruled out the old auth.conf format, we'll focus on the most likely culprits in your PE setup on AWS:

1. Verify Your HOCON auth.conf Rules Are Correct & Ordered Properly #

Even if you've set up rules for unauthenticated CSRs, the exact path matching or rule order might be tripping you up. The /puppet-ca/v1/certificate/ca endpoint needs explicit unauthenticated access for nodes to fetch the CA cert first (before submitting a CSR).

Double-check your /etc/puppetlabs/puppetserver/conf.d/auth.conf has these rules early in the list (HOCON rules match top-to-bottom, so stricter/deny rules should come after):

authorization: {
  version: 2
  rules: [
    # Allow unauthenticated nodes to fetch the CA certificate
    {
      match-request: {
        path: "/puppet-ca/v1/certificate/ca"
        type: path
        method: get
      }
      allow: "*"
      sort-order: 100
      name: "Allow unauthenticated CA cert access"
    },
    # Allow unauthenticated nodes to submit CSRs
    {
      match-request: {
        path: "/puppet-ca/v1/certificate_request"
        type: path
        method: post
      }
      allow: "*"
      sort-order: 101
      name: "Allow unauthenticated CSR submission"
    },
    # Keep your existing rules below these
  ]
}

2. Reload Puppetserver to Apply Configuration Changes #

After tweaking auth.conf, you need to reload the PE puppetserver service for changes to take effect. On your PE master node:

sudo systemctl reload pe-puppetserver
# Verify the service is running without errors
sudo systemctl status pe-puppetserver

If reload fails, check the puppetserver logs (/var/log/puppetlabs/puppetserver/puppetserver.log) for syntax errors in your HOCON config.

3. Validate AWS Security Group Port Access #

Since you're on AWS, network restrictions are a common hidden issue:

• Ensure your PE master's security group allows inbound TCP traffic on port 8140 from all your Puppet nodes (restrict to your VPC CIDR or node IP ranges for security).
• Confirm your nodes' security groups allow outbound TCP traffic on port 8140 to the PE master's IP/FQDN.

You can test connectivity from a node with:

# Linux nodes
telnet <pe-master-fqdn> 8140
# Windows nodes (PowerShell)
Test-NetConnection <pe-master-fqdn> -Port 8140

4. Check Node Puppet Config & DNS Resolution #

Make sure your nodes are pointing to the correct PE master and can resolve its FQDN:

• On nodes, verify puppet.conf (Linux: /etc/puppetlabs/puppet/puppet.conf; Windows: C:\ProgramData\PuppetLabs\puppet\etc\puppet.conf) has:

  [agent]
  server = <pe-master-fqdn>
  ca_server = <pe-master-fqdn>
  

• Test DNS resolution from a node:

  # Linux
  nslookup <pe-master-fqdn>
  # Windows
  Resolve-DnsName <pe-master-fqdn>
  

If DNS fails, nodes might be hitting the wrong server (or a load balancer misconfiguration), leading to forbidden errors.

5. Inspect Detailed CA & Puppetserver Logs #

Dig into the CA-specific logs to get more context about why the request is being denied:

# On PE master, view CA logs
tail -f /var/log/puppetlabs/puppetserver/puppetserver-ca.log

Look for lines that specify which auth rule matched the request—this will tell you if a deny rule is overriding your allow rules, or if the path/method isn't matching as expected.

6. Check PE RBAC Permissions #

PE's Role-Based Access Control (RBAC) can sometimes override auth.conf rules. Log into your PE console:

1. Navigate to Access Control > Roles
2. Check the permissions for the pe-puppet role (or any custom roles you've created)
3. Ensure there are no restrictions on puppet-ca endpoints that would block unauthenticated access

内容的提问来源于stack exchange，提问作者client eastwood