knowledge-wiki/channels/1527600968827666472.md

Channel Wiki: #vssa-dpvp-storm

Channel ID: 1527600968827666472 Created: 2026-07-23 18:22 UTC Last sync: 2026-07-28 18:36 UTC

Purpose

DPVP solution assessment and implementation planning across AWS backup, machine identity, and remote access resources.

Key Decisions

• Executive summaries belong beside each analyzed resource, not in separate summary/ folders.
• EC2 executive summaries are lean delivery-decision artifacts: focus on solution choice, AWS resources, upcoming-work impact, configuration and Terraform interface changes, costs, and decisions still required. Keep detailed supplied-evidence and delivery-evidence narratives in the full analyses rather than summary sections.
• In each EC2 executive summary, put the AWS-resource section immediately after the solution decision. List only concrete resources/components required by the selected design, with requirement conditions and exact purposes. Put upcoming-work impact immediately before cost impact.
• EC2 backup: AWS Backup is the production default for stateful/unique VMs; DLM is only an alternative for simple AMI/EBS lifecycle; immutable nodes should be rebuilt.
• EC2 machine identity: one IAM role through exactly one instance profile; application permissions and SSM operational permissions are independently gated but composed onto that one role/profile.
• EC2 remote access: native Systems Manager Session Manager and Run Command; no SSH, TCP/22, EC2 key pairs, or public administration path.
• The AWS backup resource batch is complete for EBS, EFS, S3, EC2, EKS, Lambda, and ECS/Fargate. All resource summaries use the approved delivery-decision structure and remain 🔲 Untried pending runtime/restore evidence.
• The AWS machine-identity batch is complete for EC2, Lambda, EKS, ECS/Fargate, EFS, S3, and EBS. Each summary uses the same lean resource-first structure as backup and is reconciled with its detailed YAML/HCL/output proposal.
• Machine-identity boundaries: EC2 composes independent application and SSM gates onto one role/profile; Lambda always has one execution role but exposes optional application identity separately; EKS selects Pod Identity or IRSA only after positive compatibility discovery; ECS separates task and execution roles; EFS/S3 consume exact typed workload identities; EBS guest I/O uses no IAM and exposes six separate operational identity records.
• The AWS remote-access batch is complete for EC2, ECS/Fargate, EKS, Lambda, and the deliberately aggregated EBS/EFS/S3 storage boundary. EC2 uses native SSM; ECS Exec is interactive-only and uses the task role; EKS uses access entries plus namespace RBAC and Kubernetes audit; Lambda and storage expose no interactive target and use only scoped diagnostics or already-authorized compute paths.
• Remote-access audit boundaries are explicit: CloudTrail covers AWS control-plane/API events, ECS/EKS transcript or Kubernetes audit sources cover their own request boundaries, and no source is claimed to record terminal/forwarded traffic content universally.
• EBS backup: DLM is the default for simple snapshot lifecycle; AWS Backup is the alternative for Vault Lock/WORM and centralized vault governance. DLM uses a unique explicit selector tag, while central AWS Backup uses the canonical backup = "true" tag. DLM cross-account copy requires a source share rule plus a destination-account event-based policy.
• Central AWS Backup enrollment uses exact non-null provider-derived resource ARNs plus condition.string_equals for aws:ResourceTag/backup = "true"; tag-only selection_tag is prohibited because AWS Backup unions it with Resources.
• Configuration evidence, supplemental Terraform source, deployment state, and runtime proof must remain explicitly distinguished.
• The EC2 backup executive summary must show the current checked-in configuration immediately before the proposed EC2 backup configuration, followed by a concise before/proposed comparison.

Active Topics

• Extend the authoritative configuration schema and renderer for EC2 backup enrollment, machine identity, and remote access.
• Reconcile the supplied EC2 Terraform example with canonical app-server before implementation: the example uses another VM/account and its leaf wrapper passes an empty configuration.
• Confirm whether app-server is bound to the separately configured no-IGW/no-NAT primary VPC before treating private SSM endpoints as mandatory.
• Review the completed AWS backup batch and approve the proposed schema, renderer, Terraform composition, recovery topology, and resource-specific decisions before implementation.
• Review the completed AWS machine-identity batch and approve the proposed producer/consumer contracts, ownership modes, compatibility discovery, and operational identity records before implementation.
• Review the completed AWS remote-access batch and approve the proposed SSM/ECS Exec/EKS API contracts, diagnostics boundaries, private-network assumptions, and audit ownership before implementation.

Key Context

• Repository: vssa-v1/dpvp-storm; local path /opt/data/dpvp-storm.
• Authoritative desired-state example: docs/references/project-configuration.example.yaml.
• Supplemental EC2 archive and clean extraction: docs/references/ec2-example.zip and docs/references/ec2-example/.
• Archive SHA-256: 293ceeeb9c83734e7d8f25dee1ad4279b0bde11069621299a37896c1d7de98ff.
• The supplied module unconditionally creates an SSM role/profile and optional generated SSH key path, but has no backup, application machine-identity, regional SSM, network endpoint, or operator-IAM interfaces.
• EC2 executive summaries:
  • docs/backup-solutions/aws-ec2-summary.md
  • docs/machine-identity/aws-ec2-summary.md
  • docs/remote-access/aws-ec2-summary.md
• EC2 summary sizes are 207 lines for backup, 125 for machine identity, and 175 for remote access; all remain below the 400-line limit.
• EBS backup summary: docs/backup-solutions/aws-ebs-summary.md (155 lines); supporting analysis: docs/backup-solutions/aws-ebs.md.
• Published AWS backup batch commit: 8a2d1620b0424dfa3af1ad735f234d435646662e; Gitea readback matched all 20 committed files.
• AWS backup summary sizes: EBS 155, EFS 124, S3 134, EC2 207, EKS 137, Lambda 156, and ECS/Fargate 158 lines.
• EC2 backup configuration comparison update: commit 7760f81535273911d16dde840899523bac060ebc; local and origin/main matched, and authenticated Gitea readback confirmed all comparison markers.
• Published AWS machine-identity batch commit: 5e8b91fc1c8385a142560a064e65f8463675836e; local, origin/main, Gitea API commit, and all 15 Gitea content readbacks matched.
• AWS machine-identity summary sizes: EC2 125, Lambda 125, EKS 153, ECS/Fargate 165, EFS 146, S3 164, and EBS 208 lines.
• Published AWS remote-access batch commit: 5e8acb422272c2311f63576c91ead04e572d506f; local, origin/main, Gitea API commit, and all 17 Gitea content readbacks matched.
• AWS remote-access summary sizes: EC2 175, ECS/Fargate 165, EKS 187, Lambda 175, and aggregate storage 156 lines. Normative evidence record: docs/remote-access/configuration-alignment.md.

People & Roles

• Julius: directs DPVP solution structure and executive-summary requirements.
• RootAtSkic: infrastructure/Gitea administrator.

Action Items

• 🔲 Approve the proposed configuration hierarchy and ownership boundaries.
• 🔲 Inspect the authoritative renderer and Terraform state before resource renames or migration blocks.
• 🔲 Classify app-server statefulness, RPO/RTO, and actual used/change data for backup costing.
• 🔲 Classify dsk-myapp-data attachment, statefulness, RPO/RTO, used/change data, and approved selector/copy topology.
• 🔲 Prove machine-identity allow/deny behavior, SSM runtime access, and isolated EC2 restore through Terraform plans and runtime tests.