mirror of
https://github.com/shankar0123/certctl.git
synced 2026-06-07 14:11:31 +00:00
d809874fa1
Per operator decision the framework-mapping docs are gone. They
were aspirational (no audit, no certification, no validated
mapping); keeping them around was misleading.
Files deleted (1,883 lines):
- docs/compliance/index.md
- docs/compliance/soc2.md
- docs/compliance/pci-dss.md
- docs/compliance/nist-sp-800-57.md
Hyperlinks removed:
- README.md: 'Auditor / compliance' row in the doc table; the
'(compliance mapping included)' parenthetical in the
positioning paragraph
- docs/README.md: the '## Compliance' section table; the
'Auditor / compliance team' reading-order-by-role row
Prose name-drops swept across 24 files:
- README.md: 'FedRAMP boundary CAs / financial-services policy
CAs' → '4-level boundary CAs / 3-level policy CAs';
'Compliance-grade for PCI-DSS Level 1, FedRAMP Moderate / High,
SOC 2 Type II, HIPAA' → cut entirely
- getting-started/{quickstart,concepts,examples,why-certctl,
advanced-demo}.md: 'compliance' → 'audit' / 'policy';
'PCI-DSS / SOC 2 / NIST SP 800-57' framework lists cut;
''pci': 'true'' tag example → ''environment': 'production''
- migration/cert-manager-coexistence.md: 'compliance rules' →
'policy rules'
- operator/approval-workflow.md: 'Compliance customers (PCI-DSS
Level 1, FedRAMP Moderate / High, SOC 2 Type II, HIPAA)' →
'Operators'; entire 'Compliance control mapping' table
(PCI-DSS §6.4.5 / NIST SP 800-53 SA-15 / SOC 2 Type II CC6.1
/ HIPAA §164.308(a)(4)) deleted; 'compliance contract' →
'two-person-integrity contract'; 'compliance auditors' →
'reviewers'
- operator/legacy-clients-tls-1.2.md: 'PCI-DSS v4.0 Req 4 §2.2.5'
audit-reference → CWE-326 (kept); 'PCI-DSS Req 4 §2.2.5
attestation' section retitled to 'TLS posture summary' and
rewritten without framework framing; 'PCI-DSS, NIST, and
major browsers will eventually deprecate TLS 1.2' →
'Major browsers and OS vendors will eventually deprecate
TLS 1.2'
- operator/database-tls.md: PCI-DSS Req 4 §2.2.5 audit-ref →
CWE-319 only; 'PCI-DSS scope' → 'sensitive data'; PCI-DSS
Req 4 v4.0 prose footing → cut
- operator/runbooks/disaster-recovery.md: 'SOC 2 / PCI
procurement-team deliverable' → 'on-call deliverable';
'compliance auditors' → 'reviewers'
- reference/connectors/{acme,aws-acm,azure-kv,globalsign,
local-ca,openssl,ssh,index}.md: 'compliance reporting
(PCI-DSS §3.6, HIPAA §164.312)' → 'audit reporting';
'Compliance environments (PCI-DSS Level 1, FedRAMP High,
HIPAA)' → 'Regulated environments'; 'compliance audits' →
'audit'; 'FedRAMP boundary CA' pattern names →
'4-level boundary CA' (technically descriptive)
- reference/protocols/est.md: 'compliance-hook seam' →
'device-state hook seam'; 'compliance gating' → 'device-state
gating'; 'est_compliance_failed' → 'est_device_state_failed'
- reference/protocols/scep-intune.md: 'Optional compliance
check' → 'Optional device-state check'; failure-counter
'compliance_failed' → 'device_state_failed'; 'Conditional
Access compliance gating' → 'Conditional Access
device-state gating'
- reference/intermediate-ca-hierarchy.md: 'FedRAMP boundary-CA
deployments where the regulator requires...' →
'Boundary-CA deployments where you want separation of policy
and issuing authorities'; pattern A retitled '4-level FedRAMP
boundary CA' → '4-level boundary CA'
- reference/architecture.md: broken Related-docs link to
compliance.md removed; the rest of that block had stale
pre-Phase-2 paths (quickstart.md, demo-advanced.md,
connectors.md, openapi.md, testing-guide.md, test-env.md) —
retargeted to current locations
- reference/deployment-model.md: 'SOC 2 evidence-report
generator' → 'Audit-evidence report generator'
- reference/vendor-matrix.md: 'SOC 2 / PCI auditors paste this
into evidence packs' → 'reviewers paste this into
vendor-evaluation packs'
- contributor/qa-test-suite.md: 'compliance exist' coverage
description cut; 'Compliance (PCI / SOC2 / HIPAA-relevant)'
risk-class label → 'Audit-relevant'
What was kept:
- CWE references (legitimate technical pointers)
- Microsoft API/feature names that happen to use 'compliance'
literally ('Microsoft Graph compliance API',
'device-compliance validators' — these are MS product names,
not framework name-drops)
- 'NIST PQC' on the landing page (Post-Quantum Cryptography is
the actual NIST standard family, not a compliance framework)
Verified: zero hyperlinks into docs/compliance/ remain. All 24
ci-guards/*.sh pass locally. qa-doc-seed-count.sh clean.
Net diff: 26 files / -1,883 deletions in compliance/ + -32 net
across the prose sweep.
Companion edits in cowork/ (CLAUDE.md doc-tree summary +
WORKSPACE-CHANGELOG.md retirement note) land separately.
209 lines
8.3 KiB
Markdown
209 lines
8.3 KiB
Markdown
# AWS Certificate Manager (ACM) Target Connector — Operator Deep-Dive
|
|
|
|
> Last reviewed: 2026-05-05
|
|
>
|
|
> Operator-grade documentation for the AWS Certificate Manager
|
|
> (ACM) target connector. For the connector-development context
|
|
> (interface contract, registry, atomic deploy primitive shared
|
|
> across all targets), see the [connector index](index.md).
|
|
>
|
|
> **Note:** this is the **target** connector that deploys
|
|
> certificates *into* ACM for ALB / CloudFront / API Gateway / App
|
|
> Runner consumption. The **issuer** connector that pulls certs
|
|
> *from* AWS ACM Private CA is documented separately at
|
|
> [aws-acm-pca.md](aws-acm-pca.md).
|
|
|
|
## Overview
|
|
|
|
The AWS ACM target connector deploys certificates into AWS
|
|
Certificate Manager — the public AWS service that ALB /
|
|
CloudFront / API Gateway / App Runner consume by ARN. Closes the
|
|
"we terminate TLS at AWS, how do we get certctl-issued certs to
|
|
ALB?" question for cloud-first deployments. Rank 5 of the
|
|
2026-05-03 Infisical deep-research deliverable.
|
|
|
|
Implementation lives at `internal/connector/target/awsacm/`.
|
|
|
|
## When to use this connector
|
|
|
|
Use the AWS ACM target connector when:
|
|
|
|
- TLS terminates at AWS-managed edges (ALB, CloudFront, API
|
|
Gateway, App Runner) and those services consume certs by ACM
|
|
ARN.
|
|
- You want certctl to drive the rotation while Terraform /
|
|
CloudFormation handles the ARN-to-resource attachment.
|
|
- You need short-lived IAM credentials (IRSA, instance profiles)
|
|
rather than long-lived access keys.
|
|
|
|
Look elsewhere when:
|
|
|
|
- The target is an EC2 instance running NGINX / HAProxy / Apache
|
|
directly — those connectors are simpler than the ACM round-trip.
|
|
- You're using ACM Private CA for internal trust — that's the
|
|
[aws-acm-pca.md](aws-acm-pca.md) issuer, a different connector.
|
|
|
|
## Configuration
|
|
|
|
```json
|
|
{
|
|
"region": "us-east-1",
|
|
"certificate_arn": "arn:aws:acm:us-east-1:123456789012:certificate/abcdef01-2345-6789-abcd-ef0123456789",
|
|
"tags": {"env": "production", "app": "api-gateway"}
|
|
}
|
|
```
|
|
|
|
| Field | Default | Description |
|
|
|---|---|---|
|
|
| `region` | (required) | AWS region for the ACM endpoint (e.g. `us-east-1`). CloudFront-attached certs MUST live in `us-east-1`; ALB / API Gateway use the same region as the load balancer. |
|
|
| `certificate_arn` | — | ARN of an existing ACM certificate to rotate in place. Empty on first deploy — the adapter creates a new ACM cert via `ImportCertificate` and the deployment record's Metadata captures the resulting ARN. Operators can also pre-create the ARN out-of-band (Terraform, CloudFormation) and pin it here. |
|
|
| `tags` | — | Tags applied to the ACM cert at first import + re-applied via `AddTagsToCertificate` on every subsequent import (ACM strips tags on re-import). The reserved keys `certctl-managed-by` and `certctl-certificate-id` are set automatically and cannot be overridden. |
|
|
|
|
## IAM policy (minimum permissions)
|
|
|
|
```json
|
|
{
|
|
"Version": "2012-10-17",
|
|
"Statement": [{
|
|
"Effect": "Allow",
|
|
"Action": [
|
|
"acm:ImportCertificate",
|
|
"acm:GetCertificate",
|
|
"acm:DescribeCertificate",
|
|
"acm:ListCertificates",
|
|
"acm:AddTagsToCertificate"
|
|
],
|
|
"Resource": "arn:aws:acm:*:*:certificate/*"
|
|
}]
|
|
}
|
|
```
|
|
|
|
## Auth recipes
|
|
|
|
- **IRSA (IAM Roles for Service Accounts) — recommended for K8s
|
|
deploys.** Annotate the agent's ServiceAccount with
|
|
`eks.amazonaws.com/role-arn=arn:aws:iam::<account>:role/certctl-acm-deployer`.
|
|
The role's trust policy allows the cluster's OIDC provider;
|
|
permission policy is the JSON above. Short-lived STS
|
|
credentials are auto-rotated by EKS — no long-lived access
|
|
keys.
|
|
- **EC2 instance profile — recommended for VM-based agents.**
|
|
Attach an instance profile referencing the same role. SDK's
|
|
`LoadDefaultConfig` picks credentials up via the IMDS metadata
|
|
service.
|
|
- **AWS SSO / `aws configure sso` — recommended for operator
|
|
workstations.** SDK reads `~/.aws/config` for the SSO profile
|
|
and refreshes tokens via the existing CLI session.
|
|
- **Long-lived access keys are NOT supported in connector
|
|
Config** — the credential chain is configured at the SDK
|
|
level, not the connector level. This is a procurement-
|
|
readability decision: a security reviewer reading the
|
|
`deployment_targets` table should never find an access key.
|
|
|
|
## Atomic-rollback contract
|
|
|
|
Every `DeployCertificate` snapshots the existing cert via
|
|
`DescribeCertificate` + `GetCertificate` BEFORE calling
|
|
`ImportCertificate` with the new bytes. After import, the
|
|
connector re-fetches the cert metadata and compares serial
|
|
numbers.
|
|
|
|
On serial-mismatch (post-verify failure), the connector calls
|
|
`ImportCertificate` again with the snapshotted bytes to restore
|
|
the previous cert. The rollback path emits a `WARN`-level slog
|
|
entry; the rollback's own success or failure is exposed via
|
|
`certctl_deploy_rollback_total{target_type="AWSACM",outcome="restored"|"also_failed"}`
|
|
per the deploy-hardening I Phase 10 metric exposer.
|
|
|
|
Mirrors the Bundle 5+ pre-deploy-snapshot pattern shipped for
|
|
IIS / WinCertStore / JavaKeystore.
|
|
|
|
## ALB attachment recipe
|
|
|
|
certctl creates / rotates the ACM cert; the operator (or
|
|
Terraform / CloudFormation) attaches it to the ALB listener
|
|
separately. For Terraform-driven deployments, look up the ARN by
|
|
tag:
|
|
|
|
```hcl
|
|
data "aws_acm_certificate" "certctl_managed" {
|
|
domain = "api.example.com"
|
|
most_recent = true
|
|
|
|
# Filter by certctl provenance tags so an unrelated ACM cert with
|
|
# the same SAN doesn't get picked up.
|
|
tags = {
|
|
"certctl-managed-by" = "certctl"
|
|
"certctl-certificate-id" = "mc-api-prod"
|
|
}
|
|
}
|
|
|
|
resource "aws_lb_listener" "https" {
|
|
load_balancer_arn = aws_lb.api.arn
|
|
port = 443
|
|
protocol = "HTTPS"
|
|
certificate_arn = data.aws_acm_certificate.certctl_managed.arn
|
|
# ...
|
|
}
|
|
```
|
|
|
|
The ARN updates in place across renewals (ACM `ImportCertificate`
|
|
is upsert-style when given an ARN), so the ALB listener's
|
|
`certificate_arn` reference doesn't change. CloudFront / API
|
|
Gateway distributions can reference the same ARN via their
|
|
respective Terraform resources.
|
|
|
|
## Threat model carve-outs
|
|
|
|
- **Cert key bytes never written to disk on the agent.**
|
|
`DeployCertificate` reads `request.KeyPEM` from memory and
|
|
passes it to the SDK's `ImportCertificate` call. No temp file.
|
|
No swap-out window.
|
|
- **Provenance tags are mandatory.** The reserved
|
|
`certctl-managed-by=certctl` + `certctl-certificate-id=<mc-id>`
|
|
pair is set automatically on every import. Operators
|
|
identifying a stray ACM cert in their account can match
|
|
against `certctl-managed-by` to confirm it was certctl-issued
|
|
(or NOT — the absence of the tag means a manual import).
|
|
- **No long-lived AWS credentials in `Config`.** `Config`
|
|
carries region + ARN + operator tags only. AWS auth is the
|
|
SDK credential chain (IRSA / instance profile / SSO).
|
|
- **`ListCertificates` IAM permission is required for the V2
|
|
ARN-discovery dance to work.** Operators who pin
|
|
`Config.CertificateArn` after the first deploy can drop this
|
|
permission; the V2 fallback emits a warning and reverts to
|
|
"always create new ARN" if the operator forgets to update
|
|
`certificate_arn` post-first-deploy.
|
|
|
|
## Procurement checklist crib
|
|
|
|
Paste into security review:
|
|
|
|
- certctl uses short-lived IAM-role credentials via IRSA /
|
|
instance profile, not long-lived access keys.
|
|
- The cert key is held only in agent memory during the import
|
|
call; never written to disk.
|
|
- Every imported ACM cert is tagged with
|
|
`certctl-managed-by=certctl` +
|
|
`certctl-certificate-id=<mc-id>` for forensic traceability.
|
|
- Failed imports trigger automatic rollback to the snapshotted
|
|
previous cert; both outcomes are surfaced via Prometheus.
|
|
- The minimum IAM policy is 5 actions on
|
|
`arn:aws:acm:*:*:certificate/*`; CloudTrail captures every
|
|
API call for audit.
|
|
|
|
## ValidateOnly contract
|
|
|
|
ACM has no dry-run API for `ImportCertificate`; `ValidateOnly`
|
|
returns `target.ErrValidateOnlyNotSupported` per the deploy-
|
|
hardening I Phase 3 sentinel contract. Operators preview deploys
|
|
via `ValidateConfig` + `aws acm describe-certificate
|
|
--certificate-arn <arn>` against the current ARN.
|
|
|
|
## Related docs
|
|
|
|
- [Connector index](index.md) — interface contract, registry, deploy primitive
|
|
- [Azure Key Vault](azure-kv.md) — Azure equivalent target
|
|
- [AWS ACM Private CA issuer](aws-acm-pca.md) — the *issuer* counterpart (same vendor, opposite direction)
|
|
- [Cloud targets runbook](../../operator/runbooks/cloud-targets.md) — operator playbook covering both AWS ACM and Azure KV
|