build(deps): bump react-dom from 18.3.1 to 19.2.5 in /app/services/frontend#7
Closed
dependabot[bot] wants to merge 1 commit into
Closed
Conversation
Bumps [react-dom](https://github.com/facebook/react/tree/HEAD/packages/react-dom) from 18.3.1 to 19.2.5. - [Release notes](https://github.com/facebook/react/releases) - [Changelog](https://github.com/facebook/react/blob/main/CHANGELOG.md) - [Commits](https://github.com/facebook/react/commits/v19.2.5/packages/react-dom) --- updated-dependencies: - dependency-name: react-dom dependency-version: 19.2.5 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
Author
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
timkrebs
added a commit
that referenced
this pull request
May 6, 2026
Two changes that share the same file footprint: Pin Postgres to digest (Phase 7 #7.33) - postgres:16-alpine was a rolling tag; both the StatefulSet and the migration Job consumed it. Switched to postgres:16.13-alpine@sha256:4e6e670b... so a registry rebuild can't silently swap the runtime under us. Dependabot owns the bump cadence. Harden the migration Job pod (Phase 7 #7.38) - Pod-level securityContext set: runAsNonRoot, runAsUser/Group/fsGroup 65534 (nobody), seccompProfile: RuntimeDefault. Matches the cluster PodSecurity baseline. - Container-level: allowPrivilegeEscalation false, readOnlyRootFilesystem true, capabilities dropped ALL. - automountServiceAccountToken: false. The Job only talks to the Postgres service; no K8s API calls. Reduces blast radius if the pod is compromised mid-migration. kubeconform clean on dev + staging overlays. Job is idempotent (uses IF NOT EXISTS / ON CONFLICT DO NOTHING) so re-running after the image swap is safe. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
timkrebs
added a commit
that referenced
this pull request
May 6, 2026
Three independent guardrails on the EKS + RDS components that all share the same blast radius (a single bad apply catches them all): External-DNS IRSA narrowing (Phase 7 #7.20) - Was attached to arn:aws:route53:::hostedzone/* — i.e. external-dns could mutate any zone in the AWS account. - New external_dns_hosted_zone_ids variable lists the zones this stack owns; ARNs are derived from those IDs and passed to the IRSA module. - Falls back to wildcard only when the variable is empty (very first bootstrap, before the dns component has applied). Plumb dns module's zone_id output into this variable as soon as that's possible. EKS control-plane log retention (Phase 7 #7.17) - enabled_log_types was already set; the underlying CloudWatch log group had no explicit retention. Defaulted to "Never expire" — costs grow unbounded and audit data accumulates beyond compliance windows. - 30 days in dev (cheap, debugging-oriented), 90 days elsewhere (compliance baseline). Bump to 365+ if a SOC2/PCI/HIPAA framework governs the env. Variable validation (Phase 7 #7.22) - node_desired_size / node_min_size / node_max_size: must be >= 1. Setting any to 0 in a live cluster strands all running pods and deadlocks HPA. - environment: must be in {dev, staging, prod}. Several conditionals (multi_az, deletion_protection, backup_retention) key off this exact set; a typo silently selected dev-grade defaults in non-dev envs. - db_instance_class: must match `db.<family>.<size>`. Catches the classic copy-paste-from-EC2-docs error before the apply hits AWS. terraform fmt + validate clean. The deprecation warnings on data.aws_region.current.name come from the upstream IRSA module and are unchanged. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
timkrebs
added a commit
that referenced
this pull request
May 6, 2026
Phase 7 #7.10 + #7.11 — fills the documentation gap that enterprise customers and audit teams reach for first when evaluating this architecture. Each doc is opinionated and pulls concrete file:line context from the codebase rather than restating generic best practice. docs/security-architecture.md - Trust boundary diagram (internet → ALB → gateway → mesh → DB / Vault). - Identity table — every machine and human identity, how it authenticates, what it authorizes. - /api/orders POST traced end-to-end as the canonical example. - Per-boundary controls and their current state (cites the open Phase 7 items where a control is planned but not landed). - Top-10 threat model in STRIDE form with residual severity post- mitigation; the four highest-severity items are the open Phase 7 enterprise blockers. - Compliance mapping (SOC 2 / PCI / HIPAA / ISO 27001) — informational, this is a reference architecture, not a certified deployment. docs/data-classification.md - Four levels (public / internal / confidential / restricted) with encryption, transit, and logging requirements per level. - Concrete inventory of where each level lives. - "What never goes where" rules — no PII in non-prod, no payment data, no secrets in tags / Helm values / logs. - Retention table per data class. - Operator handling rules (don't paste secrets, don't restore prod data into non-prod, etc.). docs/break-glass.md - Six recovery procedures: Vault root regen via quorum, leaked Vault token revocation, EKS access entry recovery, RDS master password reset, HCP Terraform admin lockout, AWS root account recovery. - Pre-flight checklist (named operator, paired witness, expected duration, rotation plan) — break-glass without a rotation plan is not break-glass, it's a new standing credential. - Post-incident steps (follow-up ticket, doc accuracy review, tabletop replay). docs/adr/ - 0001 Terraform Stacks over classic workspaces — why Stacks won over workspaces + Terragrunt + alternative IaC tools. - 0002 Consul Connect for east-west traffic — why Consul beat Istio and Linkerd for the HashiCorp-aligned toolchain. - 0003 Branch-based GitOps promotion — why long-lived dev/staging/ main branches beat tag-based or dispatch-based promotion for reviewer experience. docs/README.md is the index — kept short, points at each of the above plus the existing vault-root-rotation runbook. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
timkrebs
added a commit
that referenced
this pull request
May 6, 2026
The existing tests under sentinel/test/<policy>/ never ran. Sentinel's test command looks for `test/<policy>/*.[hcl|json]` *relative to the policy file's directory*, so tests at the repo-level sentinel/test/ were silently invisible — the workflow saw `[no test files]` and exited zero. IMPROVEMENTS.md Phase 2's "Sentinel test coverage" claim was technically false. Fix: - Move sentinel/test/<policy>/ → sentinel/policies/test/<policy>/. No file renames inside the directories; `git mv` preserves history. - All 6 existing policies now actually run pass + fail mocks under `sentinel test ./policies/`. Verified locally with sentinel 0.26.3. Three new policies added on top (Phase 7 #7.47): deny-iam-wildcard.sentinel — soft-mandatory. Rejects inline IAM policies that combine a wildcard Action with a wildcard Resource. Effect: Deny is exempt (deny + wildcard is a guardrail, not a grant). Service-scoped wildcards on a specific ARN are allowed. enforce-rds-retention.sentinel — hard-mandatory. Backup retention floor per env: dev >= 1, staging >= 7, prod >= 14. Also rejects skip_final_snapshot=true outside dev. Reads the environment from the resource's tags so a single Stack can have per-deployment floors. enforce-private-endpoints.sentinel — soft-mandatory. Rejects publicly_accessible=true on aws_db_instance, aws_rds_cluster, aws_redshift_cluster. Also enforces ElastiCache replication groups must have at_rest + transit encryption enabled. Soft so an admin override is possible during incident response. Each new policy ships with pass + fail mocks; verified PASS locally across all 18 test files (9 policies × pass + fail). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
timkrebs
added a commit
that referenced
this pull request
May 6, 2026
Phase 7 #7.55. The ACM cert ARN was hardcoded in app/manifests/shop/gateway.yaml — copying the dev cert into staging at build time, with no clear hook for prod to set its own. Reorganized: - base manifest still carries the dev cert (backwards-compat for anyone building base directly), but the value is now annotated as overridable in a per-overlay patch. - Added app/manifests/overlays/dev/patch-shop-ingress.yaml that re-states the dev cert + hostname so dev isn't relying on base inheritance — easier to reason about now that staging does the same. - Updated staging's patch-shop-ingress.yaml to also pin the cert ARN (previously inherited the base dev cert by accident — happens to work today because `*.netlix.dev` is a wildcard, but breaks the moment staging gets its own AWS account). When prod is provisioned (Phase 7 #7.2), add overlays/prod/ with its own patch-shop-ingress.yaml setting the prod cert ARN. No base edit required. kubeconform clean on dev + staging. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
timkrebs
added a commit
that referenced
this pull request
May 6, 2026
Phase 7 #7.54. Both web-policy and api-policy granted egress to UDP/TCP 53 against the entire kube-system namespace, not just the DNS pods. A compromised kube-system pod (CSI controllers, addon controllers, node-local cache, etc.) could have been queried as a DNS resolver and returned attacker-chosen records to the shop services. Both rules now require the destination to match both the kube-system namespace AND the k8s-app=kube-dns pod label, which is what CoreDNS ships with on EKS (verified live: coredns-* pods carry the label). This is a single AND-combined `to:` entry, not two `to:` entries — listing both selectors as siblings inside one entry is the correct NetworkPolicy syntax for "namespace AND pod label", whereas separate `to:` entries would be OR'd. kubeconform clean on dev + staging. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
timkrebs
added a commit
that referenced
this pull request
May 6, 2026
…_classification Phase 7 #7.46. The previous baseline (environment / project / managed_by) identified what a resource is and who maintains it from a Terraform standpoint, but didn't carry the labels needed for cost allocation or access policy. New mandatory tags: - owner: team / individual responsible for paging when this resource misbehaves. Pairs with the docs/IDENTITY.md plan (Phase 7 follow-up). - cost_center: cost-allocation key. Every Athena cost report relies on this being present; without it, AWS charges land in the "unallocated" bucket and become impossible to charge back. - data_classification: maps to the levels defined in docs/data-classification.md (public / internal / confidential / restricted). Drives access policies, retention, and encryption expectations. The intended set point is the AWS provider's default_tags block at the Stack level (in the tfdeploy.hcl input set) — every resource then carries them via tags_all without per-component boilerplate. The policy enforces that those Stack-level tags are actually set; if a deployment omits them, every taggable resource fails the policy and the apply blocks before any AWS calls happen. Mock updated; sentinel test passes for all 9 policies (18 mocks). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Author
|
Superseded by #31. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps react-dom from 18.3.1 to 19.2.5.
Release notes
Sourced from react-dom's releases.
... (truncated)
Changelog
Sourced from react-dom's changelog.
... (truncated)
Commits
23f4f9f19.2.590ab3f8Version 19.2.4612e371Version 19.2.3b910fc1Version 19.2.2053df4eVersion 19.2.18618113Bump scheduler version (#34671)1bd1f01Ship partial-prerendering APIs to Canary (#34633)2f0649a[Fizz] Removenonceoption from resume-and-prerender APIs (#34664)5667a41Bump next prerelease version numbers (#34639)e08f53bMatchreact-dom/statictest entrypoints and published entrypoints (#34599)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)