78 lines
8.7 KiB
Markdown
78 lines
8.7 KiB
Markdown
# Channel Wiki: #vssa-dpvp-storm
|
|
_Channel ID: 1527600968827666472_
|
|
_Created: 2026-07-23 18:22 UTC_
|
|
_Last sync: 2026-09-08 03:10 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`.
|
|
- **CONFIRMED (2026-09-07):** Authenticated account `jarvis-at-skic` has admin, push, and pull permissions on `vssa-v1/dpvp-storm`; authenticated API and SSH access both work.
|
|
- **CONFIRMED:** The repository is private and there is no separately published documentation website. The documentation source is at https://gitea.lego-cloud.eu/vssa-v1/dpvp-storm/src/branch/main/docs and requires a signed-in Gitea account with repository access.
|
|
- **OPEN ACCESS BLOCKER (2026-09-06):** Julius reported “page not found” when following the documentation link. Hermes attributed this to the private-repository authentication/authorization boundary; whether Julius subsequently gained access is **UNKNOWN**.
|
|
- 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
|
|
|
|
- 🔲 Confirm that Julius can sign in to Gitea and has access to `vssa-v1/dpvp-storm`; owner and due date **UNKNOWN**.
|
|
- 🔲 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.
|
|
|
|
## Source anchor
|
|
|
|
- Latest processed human message: `1546441933382230157` (2026-09-07 08:48 UTC; RootAtSkic confirmed Hermes has access to the `vssa-v1` organization and repository).
|