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---
This commit is contained in:
Jon Chery
@@ -76,7 +76,7 @@ Planned future features (no dates; tracked in the internal roadmap):
|
||||
consumer creates a module directly from the contract file (the
|
||||
"composition" mechanism, redesigned).
|
||||
- **Compliance milestone** — per-module compliance extension points (GDPR,
|
||||
SOX, SOC2, HIPAA, DORA) wired into the pipeline.
|
||||
SOX, SOC2, DORA) wired into the pipeline.
|
||||
- **Additional substrate adapters** — beyond the Terraform adapter.
|
||||
- **Environment self-service** — a consumer-facing flow to request and
|
||||
provision a new platform-managed environment (today it is a platform-team
|
||||
|
||||
@@ -292,7 +292,7 @@ for the full table.
|
||||
## Step 9 — Compliance extensions
|
||||
|
||||
Each module lists compliance extension points for the future compliance
|
||||
milestone (GDPR, SOX, SOC2, HIPAA, DORA). See each module's README under
|
||||
milestone (GDPR, SOX, SOC2, DORA). See each module's README under
|
||||
`modules/l1/<name>/README.md` or `modules/l2/<name>/README.md` for the
|
||||
per-module extension points. Common examples:
|
||||
|
||||
|
||||
+1
-1
@@ -63,7 +63,7 @@ Planned future features (no dates; tracked in the internal roadmap):
|
||||
consumer creates a module directly from the contract file (the "composition"
|
||||
mechanism, redesigned).
|
||||
- **Compliance milestone** — per-module compliance extension points (GDPR,
|
||||
SOX, SOC2, HIPAA, DORA) wired into the pipeline.
|
||||
SOX, SOC2, DORA) wired into the pipeline.
|
||||
- **Additional substrate adapters** — beyond the Terraform adapter.
|
||||
- **Environment self-service** — a consumer-facing flow to request and
|
||||
provision a new platform-managed environment.
|
||||
|
||||
@@ -3,7 +3,7 @@ marp: true
|
||||
theme: default
|
||||
paginate: true
|
||||
size: 16x9
|
||||
header: "Agentic Cloud Delivery Platform — How The Platform Works"
|
||||
header: "How The Platform Works"
|
||||
footer: "Internal"
|
||||
style: |
|
||||
section {
|
||||
@@ -30,10 +30,13 @@ style: |
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
# Agentic Cloud Delivery Platform — How The Platform Works
|
||||
# How The Platform Works
|
||||
|
||||
### Agentic Cloud Delivery Platform
|
||||
|
||||
<style>
|
||||
section.title h1 { font-size: 36px; }
|
||||
section.title h1 { font-size: 44px; margin-bottom: 0.1em; }
|
||||
section.title h3 { color: #F0F0F0; font-weight: 400; font-size: 22px; margin-top: 0; }
|
||||
</style>
|
||||
|
||||
---
|
||||
@@ -234,7 +237,7 @@ section { font-size: 20px; }
|
||||
- Real OIDC federation on all platform runners
|
||||
- HITL wiring for qa / prod / dr environments
|
||||
- Full regulatory ledger: S3 Object Lock + JWS signatures + daily checkpoints
|
||||
- Compliance milestone: GDPR, SOX, SOC2, HIPAA, DORA extension points
|
||||
- Compliance milestone: GDPR, SOX, SOC2, DORA extension points
|
||||
- Environment self-service provisioning
|
||||
- Dynamic module creation from a contract (agentic citizen-developer flow)
|
||||
- Additional substrate adapters (OpenTofu, Pulumi, Kubernetes CRDs)
|
||||
File diff suppressed because one or more lines are too long
@@ -1,5 +1,6 @@
|
||||
# How the Platform Works
|
||||
# How The Platform Works
|
||||
|
||||
> **Subtitle:** Agentic Cloud Delivery Platform
|
||||
> **Audience:** Senior Leadership, CTO, Head of Cloud, Head of Infrastructure, Head of DevOps
|
||||
> **Length:** ~15 minutes · 14 slides
|
||||
> **Purpose:** Sell the platform's value to tech leadership — zero-trust, security, observability, auditability, and the shift from "operators guess" to "the platform computes safety."
|
||||
@@ -239,7 +240,7 @@ The platform is **opinionated, but not painted into a corner.**
|
||||
- Real OIDC federation on all platform runners (Gitea Actions OIDC pending an upstream merge).
|
||||
- HITL wiring for qa / prod / dr environments (design shipped; wiring is next).
|
||||
- Full regulatory ledger: S3 Object Lock (7-yr compliance mode) + JWS detached signatures + daily checkpoints.
|
||||
- Compliance milestone: per-module extension points for GDPR, SOX, SOC2, HIPAA, DORA.
|
||||
- Compliance milestone: per-module extension points for GDPR, SOX, SOC2, DORA.
|
||||
- Environment self-service (a consumer-facing flow to request and provision a new environment).
|
||||
- Dynamic module creation from a contract (the agentic "citizen developer" composition mechanism).
|
||||
- Additional substrate adapters (OpenTofu, Pulumi, Kubernetes CRDs).
|
||||
|
||||
@@ -3,7 +3,7 @@ marp: true
|
||||
theme: default
|
||||
paginate: true
|
||||
size: 16x9
|
||||
header: "Agentic Cloud Delivery Platform — The Developer Experience"
|
||||
header: "The Developer Experience"
|
||||
footer: "Internal"
|
||||
style: |
|
||||
section {
|
||||
@@ -32,10 +32,13 @@ style: |
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
# Agentic Cloud Delivery Platform — The Developer Experience
|
||||
# The Developer Experience
|
||||
|
||||
### Agentic Cloud Delivery Platform
|
||||
|
||||
<style>
|
||||
section.title h1 { font-size: 36px; }
|
||||
section.title h1 { font-size: 44px; margin-bottom: 0.1em; }
|
||||
section.title h3 { color: #F0F0F0; font-weight: 400; font-size: 22px; margin-top: 0; }
|
||||
</style>
|
||||
|
||||
---
|
||||
@@ -47,7 +50,7 @@ The platform serves **two kinds of consumer** through two coordinated interfaces
|
||||
|
||||
|
||||
- **Technical developer** — owns app code + a contract + a thin CI definition
|
||||
- **Citizen developer** — declares intent in plain language; an agent produces a contract that passes the **same** safety envelope
|
||||
- **Citizen developer** — declares intent in plain language; an AI agent produces a contract that passes the **same** safety envelope
|
||||
|
||||
The platform is **opinionated in what it accepts, regardless of who is declaring.** There is no "citizen developer mode" with weaker checks.
|
||||
|
||||
@@ -57,7 +60,7 @@ The platform is **opinionated in what it accepts, regardless of who is declaring
|
||||
|
||||
Three things. That is the entire consumer-side surface.
|
||||
|
||||
|
||||
<img src="assets/png/developer-experience-02-what-dev-does.png" style="float: right; width: 45%; margin-left: 20px; margin-bottom: 10px;" />
|
||||
|
||||
The developer does **not**:
|
||||
|
||||
@@ -74,7 +77,7 @@ The developer does **not**:
|
||||
A non-technical consumer ships a production deployment **by declaring intent** — without authoring a workflow, a configuration file, or an infrastructure module.
|
||||
|
||||
- The consumer opens an issue describing what they need (e.g. "a web API for the pricing service")
|
||||
- An agent maps the intent to a contract referencing a module from the **reviewed skill catalog**
|
||||
- An AI agent maps the intent to a contract referencing a module from the **reviewed skill catalog**
|
||||
- The contract enters the **same pipeline** and must clear the **same confidence gate** before promotion
|
||||
|
||||
**Guardrails that make this safe:**
|
||||
@@ -162,17 +165,6 @@ After a successful deploy, the developer gets their connection information **wit
|
||||
|
||||
---
|
||||
|
||||
# Local Reproducibility
|
||||
|
||||
The entire CI pipeline runs **from the shell**, not just in CI. <span class="badge today">Available today</span>
|
||||
|
||||
- `scripts/run_ci.sh` mirrors the CI pipeline locally — the same three stages (lint → test → check-only) in sequence
|
||||
- `scripts/run_platform.sh --check-only` runs the platform **offline** — no AWS, no policy engine, no outbox required. Validates a contract end-to-end before pushing
|
||||
- `--plan-only` runs through the infrastructure plan without applying
|
||||
- The CI and deploy pipelines are defined by **declarative contracts** (YAML instances validated against JSON Schemas) — a single source of truth that both workflows implement. A test asserts conformance
|
||||
|
||||
---
|
||||
|
||||
# Friendly Onboarding
|
||||
|
||||
First impressions of a platform are made **when it fails for the first time.** The platform fails gracefully. <span class="badge today">Available today</span>
|
||||
@@ -196,7 +188,11 @@ Both onboarding paths end in a **sandbox dev submission that must pass the confi
|
||||
|
||||
The contract is environment-agnostic by design. Promotion is **a workflow choice, not a contract edit** — the platform raises the bar automatically.
|
||||
|
||||
**Approach A — One contract, one job per environment.** A single contract is referenced by multiple jobs; the environment is passed by each job and interpolated at runtime. The contract never changes.
|
||||
<table style="width: 100%; border: none;">
|
||||
<tr>
|
||||
<td style="width: 50%; vertical-align: top; border: none; padding-right: 12px;">
|
||||
|
||||
**Approach A — One contract, one job per environment.** The environment is passed by each job and interpolated at runtime. The contract never changes.
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
@@ -209,7 +205,10 @@ jobs:
|
||||
with: { contract: .acdl/contract.yaml, environment: qa }
|
||||
```
|
||||
|
||||
**Approach B — One job per environment, environment-specific contracts.** When inputs genuinely differ per environment, each job points at its own contract file.
|
||||
</td>
|
||||
<td style="width: 50%; vertical-align: top; border: none; padding-left: 12px;">
|
||||
|
||||
**Approach B — Environment-specific contracts.** When inputs genuinely differ per environment, each job points at its own contract file.
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
@@ -222,10 +221,15 @@ jobs:
|
||||
with: { contract: .acdl/contract-qa.yaml }
|
||||
```
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<style>
|
||||
section { font-size: 19px; }
|
||||
pre { font-size: 13px; }
|
||||
code { font-size: 13px; }
|
||||
section { font-size: 18px; }
|
||||
pre { font-size: 11px; line-height: 1.2; }
|
||||
code { font-size: 11px; }
|
||||
td { font-size: 16px; }
|
||||
</style>
|
||||
|
||||
---
|
||||
@@ -280,7 +284,7 @@ Developers pick from **pre-built, security-reviewed building blocks** — they d
|
||||
- **Modules** — composed patterns (a static site with CDN + WAF; a microservice with VPC + ECS + load balancer + registry)
|
||||
- **Validated examples per module** — `simple.yaml` + `complex.yaml` + variation files, validated against the contract schema in CI. Examples cannot drift from the schema silently
|
||||
- **Auto-promotion of patterns** — a thin-composition layer is auto-promoted to the catalog after 3 observed usages <span class="badge planned">Planned</span>
|
||||
- **Compliance extension points** — each module lists where GDPR, SOX, SOC2, HIPAA, DORA controls will wire in <span class="badge planned">Planned</span>
|
||||
- **Compliance extension points** — each module lists where GDPR, SOX, SOC2, DORA controls will wire in <span class="badge planned">Planned</span>
|
||||
|
||||
---
|
||||
|
||||
|
||||
File diff suppressed because one or more lines are too long
@@ -1,7 +1,8 @@
|
||||
# The Developer Experience
|
||||
|
||||
> **Subtitle:** Agentic Cloud Delivery Platform
|
||||
> **Audience:** Senior Leadership, CTO, Head of Cloud, Head of Infrastructure, Head of DevOps
|
||||
> **Length:** ~15 minutes · 14 slides
|
||||
> **Length:** ~15 minutes · 13 slides
|
||||
> **Purpose:** Sell the developer experience and the citizen developer experience to tech leadership — velocity without sacrificing safety, and security/observability/compliance as platform defaults rather than per-team effort.
|
||||
> **Maturity framing:** "Available today" = shipped and verified. "Planned" = on the roadmap, not yet shipped.
|
||||
|
||||
@@ -22,7 +23,7 @@ flowchart TD
|
||||
```
|
||||
|
||||
- **Technical developer** — owns app code + a contract + a thin CI definition. Uses the full module catalog and inputs.
|
||||
- **Citizen developer** — declares intent in plain language; an agent produces a contract that passes the **same** safety envelope as a senior engineer's.
|
||||
- **Citizen developer** — declares intent in plain language; an AI agent produces a contract that passes the **same** safety envelope as a senior engineer's.
|
||||
|
||||
The platform is **opinionated in what it accepts, regardless of who is declaring.** There is no "citizen developer mode" with weaker checks.
|
||||
|
||||
@@ -59,7 +60,7 @@ The developer does **not**:
|
||||
A non-technical consumer ships a production deployment **by declaring intent** — without authoring a workflow, a configuration file, or an infrastructure module.
|
||||
|
||||
- The consumer opens an issue describing what they need (e.g. "a web API for the pricing service").
|
||||
- An agent maps the intent to a contract referencing a module from the **reviewed skill catalog.**
|
||||
- An AI agent maps the intent to a contract referencing a module from the **reviewed skill catalog.**
|
||||
- The contract enters the **same pipeline** and must clear the **same confidence gate** before promotion.
|
||||
|
||||
**Guardrails that make this safe:**
|
||||
@@ -176,20 +177,7 @@ After a successful deploy, the developer gets their connection information **wit
|
||||
|
||||
---
|
||||
|
||||
## Slide 9 — Local Reproducibility
|
||||
|
||||
The entire CI pipeline runs **from the shell**, not just in CI.
|
||||
|
||||
- `scripts/run_ci.sh` mirrors the CI pipeline locally — the same three stages (lint → test → check-only) in sequence. Exits 0 with "CI PIPELINE OK." *(Available today.)*
|
||||
- `scripts/run_platform.sh --check-only` runs the platform offline — **no AWS, no policy engine, no outbox required.** Validates a contract end-to-end before pushing. *(Available today.)*
|
||||
- `--plan-only` runs through the infrastructure plan without applying.
|
||||
- The CI and deploy pipelines are defined by **declarative contracts** (YAML instances validated against JSON Schemas) — a single source of truth that both the GitHub and Gitea workflows implement. A test asserts conformance.
|
||||
|
||||
> **Speaker notes:** This is the "no 'works on my machine' for CI" slide. A developer can reproduce the exact CI behavior locally before pushing. For the Head of Engineering: this shrinks the PR-cycle time because failures are caught pre-push, and it makes the pipeline itself a reviewable artifact (the YAML contract), not tribal workflow code.
|
||||
|
||||
---
|
||||
|
||||
## Slide 10 — Friendly Onboarding
|
||||
## Slide 9 — Friendly Onboarding
|
||||
|
||||
First impressions of a platform are made **when it fails for the first time.** The platform fails gracefully.
|
||||
|
||||
@@ -308,7 +296,7 @@ Developers pick from **pre-built, security-reviewed building blocks** — they d
|
||||
- **Modules** — composed patterns (a static site with CDN + WAF; a microservice with VPC + ECS + load balancer + registry). *(Available today.)*
|
||||
- **Validated examples per module** — every module ships `simple.yaml` + `complex.yaml` + variation files, validated against the contract schema in CI. Examples cannot drift from the schema silently. *(Available today.)*
|
||||
- **Auto-promotion of patterns** — a thin-composition layer is auto-promoted to the catalog after 3 observed usages. *(Mechanism planned.)*
|
||||
- **Compliance extension points** — each module lists where GDPR, SOX, SOC2, HIPAA, DORA controls will wire in. *(Compliance milestone is planned.)*
|
||||
- **Compliance extension points** — each module lists where GDPR, SOX, SOC2, DORA controls will wire in. *(Compliance milestone is planned.)*
|
||||
|
||||
> **Speaker notes:** The catalog is what makes "declare intent" practical — you can only declare a module that exists. For leadership: the catalog is the leverage. One well-reviewed module serves every consumer; a fix to the module serves every consumer on the next run. This is the compounding asset.
|
||||
|
||||
|
||||
@@ -50,7 +50,7 @@ L1 primitive MUST declare `deletion_protection` and `encryption_enabled`
|
||||
## Compliance extension points
|
||||
|
||||
Resources this module could be extended with for the future compliance
|
||||
milestone (GDPR, SOX, SOC2, HIPAA, DORA). Not implemented yet — listed
|
||||
milestone (GDPR, SOX, SOC2, DORA). Not implemented yet — listed
|
||||
so the redesign can plan for them.
|
||||
|
||||
- **<area>** — <what could be added, e.g. KMS key for encryption>
|
||||
|
||||
@@ -431,7 +431,7 @@ Every module README MUST follow the structure of
|
||||
7. `## Usage` — a concrete snippet showing how a consumer references
|
||||
the module in a contract.
|
||||
8. `## Compliance extension points` — resources or behaviors that could
|
||||
be added for the future compliance milestone (GDPR, SOX, SOC2, HIPAA,
|
||||
be added for the future compliance milestone (GDPR, SOX, SOC2,
|
||||
DORA). Not implemented yet; listed so the redesign can plan for them.
|
||||
9. `## Examples` — links to `examples/simple.yaml` and
|
||||
`examples/complex.yaml` with a one-line description of each.
|
||||
|
||||
@@ -57,7 +57,7 @@ The `target_group_arn` output is referenced by `ecs-service` as its
|
||||
|
||||
## Compliance extension points
|
||||
|
||||
- **TLS / HTTPS listener** — add `aws_acm_certificate` + `ssl_policy` + `certificate_arn` for encryption in transit (SOC2 CC6.1, PCI-DSS 4.1, HIPAA §164.312(e)(1), GDPR Art.32).
|
||||
- **TLS / HTTPS listener** — add `aws_acm_certificate` + `ssl_policy` + `certificate_arn` for encryption in transit (SOC2 CC6.1, PCI-DSS 4.1, GDPR Art.32).
|
||||
- **Access logs** — add `access_logs { bucket = ..., prefix = ... }` to the load balancer (SOX, SOC2 CC7.2, DORA ICT audit trail).
|
||||
- **Security group rules** — add ingress/egress rules restricting traffic to known sources (SOC2 CC6.6, PCI-DSS 1.2).
|
||||
- **Health check** — add a `health_check` block to the target group (SOC2 CC7.3 monitoring, DORA operational resilience).
|
||||
|
||||
@@ -69,7 +69,7 @@ inside a module composition (see `modules/l2/static-assets`).
|
||||
- **Logging** — CloudFront access logs to an S3 bucket for auditability
|
||||
(SOC2 CC7.2, DORA audit trail).
|
||||
- **Field-level encryption** — add field-level encryption for PII fields
|
||||
in POST bodies (HIPAA §164.312(a)(2)(iv), GDPR Art.32).
|
||||
in POST bodies (GDPR Art.32).
|
||||
|
||||
## Examples
|
||||
|
||||
|
||||
@@ -45,11 +45,11 @@ The `repository_url` output is used to build the `image` input for
|
||||
|
||||
## Compliance extension points
|
||||
|
||||
- **Image scanning** — add `image_scanning_configuration { scan_on_push = true }` for vulnerability scanning (SOC2 CC7.6, DORA ICT risk testing, HIPAA security monitoring).
|
||||
- **Encryption** — add `encryption_configuration { encryption_type = "KMS", kms_key = ... }` with a customer-managed key (SOC2 CC6.1, HIPAA §164.312(a)(2)(iv), GDPR Art.32).
|
||||
- **Image scanning** — add `image_scanning_configuration { scan_on_push = true }` for vulnerability scanning (SOC2 CC7.6, DORA ICT risk testing, security monitoring).
|
||||
- **Encryption** — add `encryption_configuration { encryption_type = "KMS", kms_key = ... }` with a customer-managed key (SOC2 CC6.1, GDPR Art.32).
|
||||
- **Image tag immutability** — add `image_tag_mutability = "IMMUTABLE"` to prevent tag overwriting (SOX §802, SOC2 CC6.1 integrity, DORA audit integrity).
|
||||
- **Lifecycle policy** — add `aws_ecr_lifecycle_policy` to enforce image retention / cleanup (GDPR Art.5(2) data minimization, SOC2 CC5.2).
|
||||
- **Access policy** — add a repository policy restricting pull/push to known roles (SOC2 CC6.1, HIPAA §164.308(a)(4)).
|
||||
- **Access policy** — add a repository policy restricting pull/push to known roles (SOC2 CC6.1.
|
||||
|
||||
## Examples
|
||||
|
||||
|
||||
@@ -46,8 +46,8 @@ The `cluster_arn` output is referenced by `ecs-service` as its
|
||||
## Compliance extension points
|
||||
|
||||
- **Container Insights** — add `configuration { container_insights = "enabled" }` for observability (SOC2 CC7.3, DORA ICT risk monitoring).
|
||||
- **CloudWatch Logs** — add a log group with retention policy for cluster-level audit logs (SOX, SOC2 CC7.2, HIPAA §164.312(b)).
|
||||
- **Encryption** — add `settings { name = "containerInsights", value = "enabled" }` and KMS-based encryption for container data (HIPAA §164.312(a)(2)(iv), GDPR Art.32).
|
||||
- **CloudWatch Logs** — add a log group with retention policy for cluster-level audit logs (SOX, SOC2 CC7.2.
|
||||
- **Encryption** — add `settings { name = "containerInsights", value = "enabled" }` and KMS-based encryption for container data (GDPR Art.32).
|
||||
|
||||
## Examples
|
||||
|
||||
|
||||
@@ -64,9 +64,9 @@ provided.
|
||||
|
||||
## Compliance extension points
|
||||
|
||||
- **CloudWatch Logs** — add `logConfiguration` to the container definition with a log group + retention policy (SOX, SOC2 CC7.2, HIPAA §164.312(b), DORA ICT incident logging).
|
||||
- **CloudWatch Logs** — add `logConfiguration` to the container definition with a log group + retention policy (SOX, SOC2 CC7.2, DORA ICT incident logging).
|
||||
- **Task execution role separation** — add a separate `aws_iam_role` for execution vs. the task role (SOC2 CC6.3 segregation of duties at runtime).
|
||||
- **Secrets injection** — add `secrets` block referencing AWS Secrets Manager / SSM Parameter Store with KMS encryption (SOC2 CC6.1, HIPAA §164.312(a)(2)(iv)).
|
||||
- **Secrets injection** — add `secrets` block referencing AWS Secrets Manager / SSM Parameter Store with KMS encryption (SOC2 CC6.1.
|
||||
- **Execute command** — add `enable_execute_command` with KMS encryption for session audit (SOC2 CC7.2).
|
||||
- **Deployment circuit breaker** — add `deployment_circuit_breaker` block for resilience (SOC2 CC9.1, DORA operational resilience).
|
||||
- **Health check** — add a `health_check` block to the target group (currently missing despite the contract schema having a healthcheck field).
|
||||
|
||||
@@ -51,8 +51,8 @@ into the Terraform `assume_role_policy` argument. The
|
||||
## Compliance extension points
|
||||
|
||||
- **Permissions boundary** — add `permissions_boundary` to enforce least-privilege guardrails (SOC2 CC6.1, SOX ITGC, DORA ICT access control).
|
||||
- **Inline policy** — add `aws_iam_role_policy` for fine-grained least-privilege instead of broad managed policies (SOC2 CC6.1, HIPAA §164.308(a)(4)).
|
||||
- **MFA conditions** — add `condition` blocks requiring MFA for assume-role (SOC2 CC6.1, HIPAA §164.312(d)).
|
||||
- **Inline policy** — add `aws_iam_role_policy` for fine-grained least-privilege instead of broad managed policies (SOC2 CC6.1.
|
||||
- **MFA conditions** — add `condition` blocks requiring MFA for assume-role (SOC2 CC6.1.
|
||||
- **Source IP / region conditions** — add `aws:SourceIp` / `aws:RequestedRegion` conditions for data residency enforcement (GDPR Art.44-49, DORA ICT third-party risk).
|
||||
- **Access Analyzer** — add `aws_accessanalyzer_analyzer` to verify least-privilege (SOC2 CC6.1, GDPR Art.32).
|
||||
- **Role separation** — add a separate task role vs. execution role (SOC2 CC6.3 segregation of duties).
|
||||
|
||||
@@ -53,7 +53,7 @@ pipeline as the regression baseline).
|
||||
|
||||
## Compliance extension points
|
||||
|
||||
- **Key rotation** — automatic key rotation enabled by default (SOC2 CC6.1, HIPAA §164.312(a)(2)(iv), GDPR Art.32).
|
||||
- **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).
|
||||
|
||||
@@ -72,18 +72,17 @@ as the regression baseline).
|
||||
## Compliance extension points
|
||||
|
||||
- **KMS encryption** — add a customer-managed KMS key for storage
|
||||
encryption (`kms_key_id` argument) (SOC2 CC6.1, HIPAA §164.312(a)(2)(iv),
|
||||
encryption (`kms_key_id` argument) (SOC2 CC6.1,
|
||||
GDPR Art.32).
|
||||
- **Automated backups** — the `backup_retention_period` NFR controls
|
||||
automated backup retention; extend with backup windows + copy tags to
|
||||
another region for DR (SOX ITGC, DORA operational resilience).
|
||||
- **Audit logging via CloudTrail** — RDS does not emit CloudTrail events
|
||||
for data-plane access; add `aws_db_instance_automated_backups_replication`
|
||||
+ CloudWatch Logs for database audit (SOX, SOC2 CC7.2, HIPAA
|
||||
§164.312(b)).
|
||||
+ CloudWatch Logs for database audit (SOX, SOC2 CC7.2).
|
||||
- **IAM database authentication** — add `iam_database_authentication_enabled
|
||||
= true` so IAM users/roles can authenticate to the database without
|
||||
long-lived passwords (SOC2 CC6.1, HIPAA §164.308(a)(4)).
|
||||
long-lived passwords (SOC2 CC6.1).
|
||||
- **Read replicas** — add `aws_db_instance` with `replicate_source_db` for
|
||||
read scaling and DR failover (SOC2 CC9.1, DORA operational resilience).
|
||||
|
||||
|
||||
@@ -50,11 +50,11 @@ pipeline as the regression baseline).
|
||||
|
||||
## Compliance extension points
|
||||
|
||||
- **Encryption at rest** — add `aws_s3_bucket_server_side_encryption_configuration` with a customer-managed KMS key (SOC2 CC6.1, HIPAA §164.312(a)(2)(iv), GDPR Art.32).
|
||||
- **Encryption at rest** — add `aws_s3_bucket_server_side_encryption_configuration` with a customer-managed KMS key (SOC2 CC6.1, GDPR Art.32).
|
||||
- **Object Lock** — add `aws_s3_bucket_object_lock_configuration` in compliance mode with 7-year retention for immutable evidence (SOX §802, DORA audit trail).
|
||||
- **Access logging** — add `aws_s3_bucket_logging` to a target logging bucket (SOC2 CC7.2).
|
||||
- **Public access block** — add `aws_s3_bucket_public_access_block` to prevent data exfiltration (SOC2 CC6.1, GDPR Art.32).
|
||||
- **Lifecycle policy** — add `aws_s3_bucket_lifecycle_configuration` for retention enforcement (GDPR Art.5(2), HIPAA §164.530(j)).
|
||||
- **Lifecycle policy** — add `aws_s3_bucket_lifecycle_configuration` for retention enforcement (GDPR Art.5(2).
|
||||
|
||||
## Examples
|
||||
|
||||
|
||||
@@ -72,7 +72,7 @@ pipeline as the regression baseline).
|
||||
|
||||
## Compliance extension points
|
||||
|
||||
- **KMS encryption for EFS** — encrypt the EFS volume that persists uptime-kuma state with a customer-managed KMS key (SOC2 CC6.1, HIPAA §164.312(a)(2)(iv), GDPR Art.32).
|
||||
- **KMS encryption for EFS** — encrypt the EFS volume that persists uptime-kuma state with a customer-managed KMS key (SOC2 CC6.1, GDPR Art.32).
|
||||
- **HTTPS/TLS for the ALB** — attach an ACM certificate and HTTPS listener to the ALB so the dashboard is served over TLS (SOC2 CC6.1, GDPR Art.32).
|
||||
- **WAF in front of uptime dashboard** — place a WAF web ACL in front of the ALB to protect the dashboard from common exploits (SOC2 CC7.2).
|
||||
- **Secrets Manager for alert webhook URLs** — store Teams webhook URLs and other credentials in AWS Secrets Manager rather than plaintext inputs (SOC2 CC6.1, GDPR Art.32).
|
||||
|
||||
@@ -54,8 +54,8 @@ modules reference `subnet_ids` for their network placement.
|
||||
|
||||
## Compliance extension points
|
||||
|
||||
- **VPC Flow Logs** — add `aws_flow_log` + CloudWatch Logs group / S3 destination (SOX ITGC, SOC2 CC7.2, HIPAA §164.312(b), DORA ICT risk logging).
|
||||
- **Private subnets + NAT gateway** — add private subnets with a NAT gateway so ECS tasks don't need public IPs (SOC2 CC6.6, PCI-DSS 1.3, HIPAA network isolation).
|
||||
- **VPC Flow Logs** — add `aws_flow_log` + CloudWatch Logs group / S3 destination (SOX ITGC, SOC2 CC7.2, DORA ICT risk logging).
|
||||
- **Private subnets + NAT gateway** — add private subnets with a NAT gateway so ECS tasks don't need public IPs (SOC2 CC6.6, PCI-DSS 1.3, network isolation).
|
||||
- **VPC endpoints** — add S3, ECR, KMS, DynamoDB, CloudWatch interface/gateway endpoints to keep traffic off the public internet (SOC2 CC6.7, GDPR Art.32(1)(a), DORA ICT third-party risk).
|
||||
- **Security groups** — add `aws_security_group` as a first-class sub-resource (currently missing; needed for all regulated deployments) (SOC2 CC6.6, PCI-DSS 1.2).
|
||||
- **Network ACLs** — add `aws_network_acl` for subnet-level segmentation (PCI-DSS 1.3).
|
||||
|
||||
@@ -53,7 +53,7 @@ inputs:
|
||||
## Compliance extension points
|
||||
|
||||
The pattern can wire compliance resources across primitives when the
|
||||
compliance milestone (GDPR, SOX, SOC2, HIPAA, DORA) lands:
|
||||
compliance milestone (GDPR, SOX, SOC2, DORA) lands:
|
||||
|
||||
- **KMS key** — shared encryption key referenced by S3, ECR, CloudWatch Logs, and Secrets Manager.
|
||||
- **CloudTrail** — management-plane audit trail for the entire stack.
|
||||
|
||||
@@ -75,7 +75,7 @@ READMEs for the underlying primitives.
|
||||
## Compliance extension points
|
||||
|
||||
The pattern can wire compliance resources when the compliance
|
||||
milestone (GDPR, SOX, SOC2, HIPAA, DORA) lands:
|
||||
milestone (GDPR, SOX, SOC2, DORA) lands:
|
||||
|
||||
- **KMS key** — shared encryption key for S3 SSE.
|
||||
- **S3 access logs** — access logging to a separate audit bucket.
|
||||
|
||||
Reference in New Issue
Block a user