Files
acdl/modules/l1/kms-key/README.md
T
Jon Chery 2682719f24
acdl-ci / Lint (push) Successful in 7s
acdl-ci / Test (push) Successful in 26s
acdl-ci / Platform check-only (offline) (push) Successful in 8s
docs(P47): presentation slide updates + HIPAA removal from all docs
Presentation changes (both Marp decks + source markdown):
1. Title slide: deck title as H1 (slightly bigger), 'Agentic Cloud Delivery
   Platform' as H3 subtitle — cleaner title hierarchy
2. DX deck: removed Local Reproducibility slide (not beneficial for DX)
3. DX deck: Safe Promotion Path slide redesigned with side-by-side layout
   for Approaches A and B (HTML table, two columns)
4. DX deck: 'an agent' → 'an AI agent' (slide 2 + Citizen Developer slide)
5. DX deck: What a Developer Does — diagram floated to the right side
6. Header simplified to just the deck name (subtitle now on title slide)

HIPAA removal (25 files):
- Completely removed all HIPAA references from all markdown documentation,
  presentation source files, module READMEs, and rendered HTML
- Removed HIPAA from compliance milestone lists (GDPR, SOX, SOC2, DORA remain)
- Removed HIPAA section references (§164.xxx) from compliance annotations
- Cleaned up empty parentheses and broken commas left by removal
- Re-rendered both HTML decks from updated Marp source

---ci---
phase: 47
milestone: v1.9
status: complete
requirements:
  covered: []
  partial: []
---/ci---
2026-07-23 14:08:40 +00:00

99 lines
2.7 KiB
Markdown

# kms-key — KMS customer-managed key
> **Module kind:** primitive | **Version:** 1.0.0
A customer-managed KMS key for per-stack encryption. Created with key
rotation enabled. One key per L2 deployment (no shared keys).
## Resources
| Resource | Type | Purpose |
|----------|------|---------|
| kms-key | `aws_kms_key` | The KMS customer-managed key |
## Inputs
| Name | Type | Required | Default | Description |
|------|------|----------|---------|-------------|
| `description` | string | yes | — | Description of the KMS key |
| `region` | string | yes | — | AWS region the KMS key is created in |
| `deletion_window_days` | number | no | 30 | Number of days before the key is deleted after deletion is requested |
## Outputs
| Name | Type | Description |
|------|------|-------------|
| `kms_key_arn` | arn | The ARN of the KMS key |
| `kms_key_id` | string | The ID of the KMS key |
## NFRs
| Name | Type | Default | Description |
|------|------|---------|-------------|
| `enable_rotation` | boolean | true | Enable automatic key rotation |
| `deletion_protection` | boolean | true | Prevent key destruction |
| `encryption_enabled` | boolean | true | Encryption is always enabled for a KMS key |
## Usage
```json
{
"id": "kms-key",
"type": "aws:kms:key",
"module": "kms-key@1.0.0",
"inputs": {
"description": "ACDL per-stack CMK",
"region": "us-east-1"
}
}
```
A concrete instance is at `instance.json` (used by the platform
pipeline as the regression baseline).
## Compliance extension points
- **Key rotation** — automatic key rotation enabled by default (SOC2 CC6.1, GDPR Art.32).
- **Deletion protection** — pending deletion window prevents accidental destruction (SOC2 CC7.2).
- **Key policy** — restrict key usage to the stack's IAM roles (SOC2 CC6.1, GDPR Art.32).
- **Audit logging** — CloudTrail logs all KMS API calls (SOC2 CC7.2, DORA audit trail).
## Examples
Validated example contracts are in [`examples/`](examples/). The platform-test
pipeline validates them against `schemas/contract.schema.json`.
### Simple
A minimal deployment:
[`examples/simple.yaml`](examples/simple.yaml)
```yaml
uses: acdl/pipelines/deploy.yaml@v1.8
module: kms-key
environment: dev
inputs:
description: "Simple CMK for testing"
region: us-east-1
```
### Complex
A production deployment with optional inputs:
[`examples/complex.yaml`](examples/complex.yaml)
```yaml
uses: acdl/pipelines/deploy.yaml@v1.8
module: kms-key
environment: dev
inputs:
description: "Production CMK with 90-day deletion window"
region: us-east-1
deletion_window_days: 90
```
## Versioning
`1.0.0` — interface MAJOR, behavior MINOR, lifecycle PATCH. MAJOR bumps
require a new registry entry (immutable publication); old entries enter
a 12-month deprecation window.