# Official sources

Use this reference only when you need source grounding for AWS service behavior or the detailed source list.

## AWS documentation

Use these as starting points, not as proof of the user's live AWS state:
- https://docs.aws.amazon.com/privateca/latest/userguide/ca-best-practices.html
- https://docs.aws.amazon.com/privateca/latest/userguide/PCACertInstall.html
- https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html
- https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html

## Grounding rule

Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, entitlement, or operational state. Prefer read-only AWS MCP or CLI evidence, repository evidence, or sanitized user-provided evidence for current-state claims.

## Current MCP/documentation refresh (2026-06-02)

Service facts from official docs:
- AWS Private CA best practices include documenting CA structure and policies, minimizing root CA use, giving root CA its own account, separating administrator and issuer roles, managed revocation, CloudTrail, and blocking public CRL access.
- Installing CA certificates differs for root and subordinate CAs and depends on compatible signing algorithms and activation steps.

Sampled live evidence:
- Read-only regional availability sampling reported AWS Private CA and ACM as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
- Sampled APIs `ACM PCA+DescribeCertificateAuthority` and `ACM+DescribeCertificate` were reported `isAvailableIn` in those regions.

Review implications:
- Issuer review requires CA hierarchy, policy/OID constraints, revocation path, issuer/admin separation, key protection, CloudTrail, certificate templates, renewal, and trust-store impact evidence.
- CA availability does not prove safe issuance policy or trust boundary.

# Private CA Issuer Trust Boundaries Guide

Use this reference for AWS ACM Private CA issuer reviews involving cert-manager `AWSPCAIssuer`, `AWSPCAClusterIssuer`, IRSA, certificate templates, subordinate CA usage, CRL reachability, cross-account CA sharing, and Kubernetes certificate issuance.

## What people get wrong

The lazy story is:

> cert-manager can issue certificates, so the issuer is configured correctly.

Wrong. A working issuer can still mint the wrong certificate class, use the wrong CA tier, bypass namespace boundaries, break revocation, or grant cert-manager CA-administration permissions.

Common bad assumptions:

- A ROOT CA ARN is acceptable if issuance works.
- Any ACM PCA template is safe for workloads.
- IRSA permissions can be broad because cert-manager is trusted infrastructure.
- CRL distribution is optional for private workloads.
- Cross-account PCA sharing removes the need for tight security-account controls.
- Long workload certificate duration is operationally safer.

## Private-CA failure modes

- `AWSPCAIssuer` or `AWSPCAClusterIssuer` references a root CA instead of subordinate CA.
- Certificate template allows subordinate CA issuance instead of end-entity certificates.
- IRSA role includes `CreateCertificateAuthority`, `DeleteCertificateAuthority`, broad resource `*`, or unrelated PCA actions.
- Cluster-scoped issuer allows namespaces to request certificates outside their trust boundary.
- CRL S3 distribution point is unreachable from clients, disabling practical revocation.
- Cross-account RAM/shared CA policy grants issuance without namespace/cluster/account guardrails.

## Minimum safe workflow

1. Identify issuer kind, namespace scope, CA ARN, CA type, template ARN, Kubernetes service account, and IRSA role.
2. Verify CA hierarchy: workload issuers use subordinate CA, not root CA; root remains offline/highly restricted.
3. Verify certificate template is end-entity only unless there is explicit approved subordinate-CA issuance use case.
4. Review IAM/IRSA for minimum issuance actions: IssueCertificate, GetCertificate, DescribeCertificateAuthority.
5. Check certificate duration, renewBefore, key usages, SANs, namespace boundaries, and approval policy.
6. Verify CRL/OCSP/revocation distribution reachability and audit logging.
7. Require explicit approval before changing CA, issuer, template, or IRSA policy.

## Verification targets

- cert-manager `Certificate`, `Issuer`, `ClusterIssuer`, `AWSPCAIssuer`, and `AWSPCAClusterIssuer` YAML fields
- ACM Private CA type, state, ARN, certificate template ARN, CRL configuration, audit report, and CloudTrail issuance events
- IRSA role trust policy, service account annotation, IAM actions/resources, and permissions boundary/SCP effects
- Kubernetes namespace/RBAC boundaries, approver policy, cert-manager logs/events, and certificate request status
- CRL S3 bucket policy, KMS policy, network reachability, client trust stores, and revocation test evidence
- cross-account RAM/shared CA permissions and security-account ownership

## When to push back

Push back if the user asks to:

- issue workload certificates directly from a root CA
- allow cert-manager to mint subordinate CAs
- grant broad ACM PCA admin actions to IRSA
- ignore CRL reachability or revocation evidence
- approve long-lived workload certificates without risk acceptance
- treat successful issuance as proof of safe PKI posture

# Safety checklist

Use this reference before any recommendations on cert-manager PKI configuration, IRSA policy changes, CA hierarchy decisions, or CRL distribution point design.

## Non-negotiables

- Never ask users to paste secrets, access keys, private keys, CA passwords, or PKCS#12 bundles into chat.
- Prefer official AWS MCP tools or sanitized `kubectl get` / `aws acm-pca` CLI output for current-state evidence. Label the evidence level.
- Do not invent CA ARNs, certificate template ARNs, IRSA role ARNs, or RAM resource share IDs.
- Require explicit platform-team sign-off before any change that modifies a CA hierarchy, revokes a CA, or deletes a PCA CRL S3 bucket.
- Keep IRSA permissions scoped to the minimum: `acm-pca:IssueCertificate`, `acm-pca:GetCertificate`, `acm-pca:DescribeCertificateAuthority`.

## PKI attack vector: required awareness

cert-manager with an `AWSPCAClusterIssuer` that has `acm-pca:IssueCertificate` via IRSA can issue certificates for any DNS name trusted by your internal PKI. A compromised cert-manager pod is equivalent to a compromised subordinate CA. Always review:
- Which namespaces can request from this ClusterIssuer (CertificateRequestPolicy coverage)
- Whether the CA certificate template allows sub-CA issuance (SubordinateCACertificate templates are CRITICAL)
- Whether the certificate SAN validation enforces DNS name scope

## Stress checks

- Which workloads trust this CA chain — blast radius of CA compromise?
- Can cert-manager request certificates for arbitrary SANs without CertificateRequestPolicy guard?
- Is the CA ROOT or SUBORDINATE? (ROOT issuance is CRITICAL)
- Is the CRL S3 bucket reachable from all pods that verify TLS using this CA?
- Is cross-account RAM share scoped to specific organizational units?

## Evidence labels

Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live AWS state.

# Workflow and Output Contract

## Review Workflow

### Step 1 — Identify the issuer resource type

Determine whether the configuration uses `AWSPCAIssuer` (namespace-scoped) or `AWSPCAClusterIssuer` (cluster-scoped):

```bash
kubectl get awspcaissuer -A
kubectl get awspcaclusterissuer
```

Retrieve the issuer spec:

```bash
kubectl get awspcaissuer <name> -n <namespace> -o yaml
kubectl get awspcaclusterissuer <name> -o yaml
```

Key fields to extract:
- `spec.arn` — the CA ARN (must be a SUBORDINATE CA, not ROOT)
- `spec.region` — AWS region of the CA
- `spec.signingAlgorithm` — signing algorithm
- `spec.template.arn` — certificate template ARN (controls what types of certs can be issued)

### Step 2 — Validate CA ARN type

Use the AWS CLI to confirm the CA type:

```bash
aws acm-pca describe-certificate-authority \
  --certificate-authority-arn <arn> \
  --query 'CertificateAuthority.Type' \
  --output text
```

Expected output: `SUBORDINATE`

If output is `ROOT` — this is a CRITICAL finding. cert-manager is directly wired to the root of trust.

Also check CA status:
```bash
aws acm-pca describe-certificate-authority \
  --certificate-authority-arn <arn> \
  --query 'CertificateAuthority.Status' \
  --output text
```

Expected: `ACTIVE`. If `DISABLED` or `DELETED`, the issuer will fail silently until the CA is restored.

### Step 3 — Validate certificate template ARN

The template ARN controls what type of certificate ACM PCA will issue. Common template ARNs:

| Template ARN Suffix | Purpose | Risk |
|---------------------|---------|------|
| `EndEntityCertificate/V1` | Standard workload cert | Safe — correct choice |
| `EndEntityClientAuthCertificate/V1` | Client auth cert | Safe for mTLS |
| `SubordinateCACertificate_PathLen0/V1` | Subordinate CA cert | CRITICAL — allows sub-CA issuance |
| `SubordinateCACertificate_PathLen1/V1` | Subordinate CA with chain | CRITICAL |
| `RootCACertificate/V1` | Root CA cert | CRITICAL |

Full ARN format:
```
arn:aws:acm-pca:::template/EndEntityCertificate/V1
```

If no template is specified in the issuer, PCA defaults to `EndEntityCertificate/V1` — verify this assumption against the actual ACM PCA issuance policy.

### Step 4 — Review IRSA IAM role policy

Retrieve the IAM role attached to the cert-manager ServiceAccount:

```bash
kubectl get serviceaccount cert-manager -n cert-manager -o jsonpath='{.metadata.annotations.eks\.amazonaws\.com/role-arn}'
```

Retrieve and review the role policy:

```bash
aws iam list-role-policies --role-name <role-name>
aws iam get-role-policy --role-name <role-name> --policy-name <policy-name>
```

Minimum required IAM policy:

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

**Flag as HIGH if the policy includes any of:**
- `acm-pca:DeleteCertificateAuthority`
- `acm-pca:CreateCertificateAuthority`
- `acm-pca:UpdateCertificateAuthority`
- `acm-pca:RestoreCertificateAuthority`
- `acm-pca:*` (wildcard)
- Resource set to `*` instead of scoped CA ARN

### Step 5 — Review Certificate validity periods

List all cert-manager Certificate resources and their durations:

```bash
kubectl get certificate -A -o custom-columns=\
NAMESPACE:.metadata.namespace,\
NAME:.metadata.name,\
DURATION:.spec.duration,\
RENEW_BEFORE:.spec.renewBefore,\
ISSUER:.spec.issuerRef.name
```

Validity guidelines:
- Workload certs: <= 90d (best practice), <= 365d (acceptable)
- Internal service mesh mTLS: <= 24h (optimal)
- Long-lived infrastructure certs: <= 2y (acceptable with documented justification)

Note: ACM PCA silently caps certificate validity at the CA's own remaining validity. A cert with `duration: 87600h` (10 years) issued by a CA expiring in 2 years will be capped at 2 years without error. Always verify the CA's own expiration date:

```bash
aws acm-pca describe-certificate-authority \
  --certificate-authority-arn <arn> \
  --query 'CertificateAuthority.NotAfter' \
  --output text
```

### Step 6 — Review CRL configuration and reachability

Check the CRL configuration on the CA:

```bash
aws acm-pca describe-certificate-authority \
  --certificate-authority-arn <arn> \
  --query 'CertificateAuthority.RevocationConfiguration'
```

Verify the CRL S3 bucket name from the output. Then check reachability from within the VPC:

- Does the VPC have an S3 Gateway VPC endpoint for the CRL bucket's region?
- Is the CRL S3 bucket policy allowing access from the VPC?
- Is the CRL distribution point URL embedded in issued certs accessible?

```bash
# Check for S3 gateway VPC endpoint
aws ec2 describe-vpc-endpoints \
  --filters "Name=service-name,Values=com.amazonaws.<region>.s3" \
             "Name=vpc-id,Values=<vpc-id>"
```

If the CRL S3 bucket requires a VPC endpoint and none exists, revocation checking is effectively disabled (most TLS clients soft-fail on CRL/OCSP unreachability).

### Step 7 — Cross-account PCA review (if applicable)

Identify if the CA ARN belongs to a different AWS account than the EKS cluster:

```bash
# Extract account ID from CA ARN
echo "arn:aws:acm-pca:<region>:<account-id>:certificate-authority/<id>"
# Compare with current account
aws sts get-caller-identity --query Account --output text
```

For cross-account configurations:

1. Verify the RAM share exists in the security account:
```bash
aws ram list-resources --resource-owner SELF --resource-type acm-pca:CertificateAuthority
```

2. Verify the workload-account IRSA role trust policy references the correct EKS OIDC provider.

3. Confirm the cross-account IAM permissions follow least-privilege (issuance only, not management).

---

## Output Format

### Finding: `<short title>`

| Field | Value |
|-------|-------|
| Severity | CRITICAL / HIGH / MEDIUM / LOW |
| Resource | AWSPCAIssuer name, CA ARN, IAM role, or cert name |
| Evidence | documentation-based / live evidence / inference |
| Description | What is wrong and why it matters for PKI trust |
| Remediation | IAM policy snippet, ARN change, or configuration fix |

---

### Overall PKI Trust Posture

| Category | Status |
|----------|--------|
| CA hierarchy (subordinate only) | PASS / FAIL |
| Certificate template scope | PASS / FAIL |
| IRSA permissions (least-privilege) | PASS / FAIL |
| Certificate validity periods | PASS / FAIL |
| CRL reachability | PASS / FAIL |
| Cross-account configuration | PASS / N/A / FAIL |

**Verdict:** TRUSTED / UNTRUSTED / CONDITIONAL (list conditions)