AWS Private CA

The AWS Private CA upstream authority integrates SPIRL with AWS Private Certificate Authority. Instead of operating as a self-signed root CA, the Trust Domain Server obtains its intermediate CA certificate from AWS Private CA, chaining the SPIFFE trust bundle to a corporate PKI root.

How it works

On startup (or after a CA rotation), the Trust Domain Server generates a fresh ECDSA key pair and requests an intermediate CA certificate from the configured AWS Private CA. The certificate is issued using the SubordinateCACertificate_PathLen0/V1 template, which sets pathLen=0 and includes the configured X.509 extensions. The Trust Domain Server then uses this intermediate CA to sign workload SVIDs.

How to Deploy

Step 1 — Set Up AWS Private CA

1. Create an AWS Private CA in the desired region (Root or Subordinate CA mode).
2. Ensure the Trust Domain Server's IAM role has the following permissions on the PCA ARN:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "acm-pca:DescribeCertificateAuthority",
        "acm-pca:IssueCertificate",
        "acm-pca:GetCertificate"
      ],
      "Resource": "arn:aws:acm-pca:<region>:<account>:certificate-authority/<ca-id>"
    }
  ]
}

For EKS deployments, use IRSA to associate this role with the Trust Domain Server's service account.

Step 2 — Update cluster configuration

section: UpstreamAuthority
schema: v1
spec:
  extensions:
    awsPca:
      certificateAuthorityArn: "arn:aws:acm-pca:us-east-1:123456789012:certificate-authority/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
      region: "us-east-1"
      signingAlgorithm: SHA256WITHECDSA
      assumeRoleArn: ""

Apply it using spirlctl:

spirlctl config set trust-domain-deployment --id <deployment-id> upstream-authority.yaml

Or using Terraform:

resource "spirl_cluster_config" "upstream_authority" {
  cluster_id = spirl_cluster.my_cluster.id
  sections = {
    UpstreamAuthority = <<-YAML
      section: UpstreamAuthority
      schema: v1
      spec:
        extensions:
          awsPca:
            certificateAuthorityArn: "arn:aws:acm-pca:us-east-1:123456789012:certificate-authority/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
            region: "us-east-1"
            signingAlgorithm: SHA256WITHECDSA
    YAML
  }
}

Once a configuration document passes validation and is stored, the Defakto control plane syncs it to your Trust Domain Servers automatically. No server or agent restart is required.

Configuration Reference

Field	Required	Default	Description
certificateAuthorityArn	Yes	—	Full ARN of the AWS Private CA.
region	No	AWS SDK default	AWS region override (e.g. us-east-1). If not specified, resolved by the AWS SDK from the environment.
signingAlgorithm	No	CA's configured algorithm	Signing algorithm for the issued intermediate CA certificate. If not specified, resolved from the CA's configuration at startup.
assumeRoleArn	No	—	IAM role ARN to assume before calling the PCA API. Useful for cross-account deployments.

Step 3 — Verify

On startup, the Trust Domain Server logs the intermediate CA certificate it received from AWS Private CA. The SPIFFE trust bundle published to agents will include the AWS Private CA root as an upstream root.

Verify the trust bundle using:

spirlctl trust-bundle get --cluster-id <cluster-id>

The output should include the AWS Private CA root in the X.509 authorities section.

Migration

To migrate from the default self-signed CA to AWS Private CA:

1. Apply the UpstreamAuthority Managed Config with the awsPca extension.
2. The Trust Domain Server picks up the new configuration automatically. At the next CA rotation, it fetches a new intermediate CA certificate from AWS PCA and begins issuing SVIDs chained to it.
3. Agents automatically receive the updated trust bundle (including the new upstream root) on their next bundle refresh.
4. SVIDs signed with the old self-signed CA remain valid until they expire.

Relying parties that trust only the old self-signed root will fail to verify new SVIDs. Update relying party trust stores before or during migration.

Security Considerations

• Intermediate CA, not root. The Trust Domain Server holds a pathLen=0 intermediate CA certificate. It cannot issue intermediate CAs, only leaf SVIDs.
• CA TTL. Short CA TTLs limit the window of exposure if the Trust Domain Server is compromised. The Trust Domain Server renews the intermediate CA automatically before expiry.
• CloudTrail. Every acm-pca:IssueCertificate call is logged in CloudTrail.
• Cross-account. Use assumeRoleArn when the PCA is in a different AWS account from the Trust Domain Server.