Skip to content
VietGara Docs

RELEASE PLAN — PHASE 8

VietGara — Security & Support Access

Version 8.0 — October 9, 2026 · Cloud: Google Cloud Platform (GCP) · Backend: Go

1. Introduction

The Release 1.5 review found no rate limiting, no Compliance Checklist (although several documents cite it) and no security review on record. Separately, platform administration is all-or-nothing today: the platform_admins table grants every right, and the list comes from PLATFORM_ADMIN_EMAILS.

This phase fixes both:

RoleRights
Platform adminEvery platform permission, including viewing any garage’s data. Bootstrapped from configuration, so it cannot be locked out by a UI mistake; at least two are recommended. Needs no approval from garage owners; every access is logged
Admin staffA user with platform roles given through platform staff groups. No data of any garage unless a support grant allows it, then read-only

Admin staff are modelled like garage staff: the platform admin creates a group, adds a user, and assigns roles (sets of permissions) to the group.

Risk until this phase ships: the mobile apps and the public quote links reach an API without rate limiting. Keep Release 8.0 first, and keep the store listings (the public step of Release 2.0) behind it. Internal and TestFlight builds are fine meanwhile.

2. Overview of the 3 Releases

ReleaseNameMain ModulesDemoable Value
8.0Security & EdgeKong, Security Architecture, Compliance ChecklistA burst of sign-in attempts is throttled at the gateway; the security review is on record
8.1Platform Staff & RolesIdentity, Platform administration, admin web and appA platform admin creates a group of support staff with a role; they sign in and see only what the role allows
8.2Read-only Support AccessSupport grants, audit, notificationsSupport staff, with the owner’s approval, read one garage’s data for an incident, and the owner sees every access

3. Release Details

Release 8.0 — Security & Edge

  • Compliance Checklist. Write the document the plans already cite: Decree 13/2023 (personal data), e-invoicing (Decree 123/2020), cybersecurity, payments, tax and accounting records. Each item has an owner, a status and the release that makes it compliant. Sections 2, 3, 5, 6 and 8 are reviewed in this release.
  • Security review. Review the Security Architecture against the code: authorization on every endpoint, row-level security coverage, token handling, file access (the registry of Release 5.0), logs without personal data, dependency and image scanning in CI. Findings are tracked to closure. Scope the yearly penetration test (NFR-SE-06) and book it before Phase 16.
  • Kong rate limiting. Add the rate-limiting plugin per route:
    • strict, per IP and per user, on sign-in, registration, OTP verification and resend, and password reset;
    • strict on the public quote-link routes;
    • a looser default for everything else, with headers for remaining quota.
    • Limits live in the declarative config and are overridable per environment.
  • Edge headers. HSTS, content-type, frame and referrer headers, a content security policy for both web consoles, and an explicit CORS policy for production hosts.
  • Definition of Done: a scripted burst of 100 wrong sign-ins from one IP is answered with 429 after the configured threshold; legitimate traffic is unaffected; the checklist and the review report are merged with no open high-severity finding.

Release 8.1 — Platform Staff & Roles

  • Platform permissions. A fixed catalogue grouped by module, each with read and write like the garage catalogue (FR-IAM-03): plan, subscription, stats (platform dashboards), garage_directory (names and owners only, no business data), user (look up a user, no password or token data), platform_staff (manage staff, groups and roles), support (open and use support grants), audit (read the platform audit log).
  • Tables (platform scope, no garage_id): platform_roles, platform_role_permissions, platform_staff_groups, platform_staff_group_members, platform_staff_invitations. The permission engine is shared with the garage RBAC, with a different scope. platform_admins keeps the super admins.
  • Authorization. Every /api/v1/admin/... endpoint moves from “is a platform admin” to a permission check; a platform admin passes them all. Authorization is evaluated per request from the database (ADR-007), so removing a user from a group applies at once.
  • Invitation. A platform admin invites an existing user by e-mail to a platform staff group; the user accepts, as for garage staff.
  • MFA (Release 6.1) is optional for the platform admin and for every user in a platform staff group.
  • Admin web and admin app. Screens for staff, groups and roles; menus filtered by permission; a user without any platform permission sees the access-denied screen as today. The admin app (Release 2.1) changes from “platform admins only” to “any user with at least one platform permission”.
  • Audit. Creating, changing and removing roles, groups and members, and every platform sign-in, are written to the audit log.
  • Definition of Done: a platform admin creates the group Billing support with a role that has subscription.read only and adds a user; that user signs in, sees the subscriptions screen but not plans, and an attempt to edit is refused; removing the user from the group blocks the next request.

Release 8.2 — Read-only Support Access

  • Support grant. A support_access_grants row: the garage, the admin staff user, a reason or ticket reference, the scope (read-only), an expiry (default 24 hours, at most 7 days), who requested it, who approved it and when, and a revoked-at time.
  • Approval. Admin staff request a grant for one garage. The garage owner approves it, by a button in the app or an e-mail link (the owner can also open one from an incident). A platform admin needs no approval: opening a garage only asks for a reason, which is logged, and the owner is notified.
  • What a support session can do.
    • Read the garage’s data in a read-only database transaction under the grant; it cannot change anything and cannot act as the owner or a staff member (no impersonation).
    • Use diagnostic views: look up a request by trace id, see outbox and event status and the notification log.
    • See a visible “Support session” banner in the console.
  • Visibility to the owner. A Support access log in garage settings lists every grant (who, why, when, how long) and every entity opened; the owner can revoke a grant at once.
  • Audit. Every support read is written to the immutable audit log with the user, the garage, the entity and the time.
  • Masking. Hiding sensitive fields (phones, tax IDs, e-mails) in support sessions is good to have but not scheduled before the Scheduling phase; it stays on the backlog.
  • No writes. A write permission for support is not offered. It can be considered later, with its own approval step.
  • Definition of Done: admin staff request access to garage gara1-1; the owner approves; the staff member reads a settlement and a customer in a read-only session with the banner showing; the owner sees both reads in the log, revokes the grant, and the next request of the staff member is refused; a platform admin opens the same garage with a reason and the owner is notified.

4. Dependency Diagram

flowchart TD
  P7(["Phase 7 complete"]) --> R80["Release 8.0<br/>Security & edge"]
  P7 --> R81["Release 8.1<br/>Platform staff & roles"]
  P6(["Phase 6 complete (MFA)"]) --> R81
  R81 --> R82["Release 8.2<br/>Read-only support access"]
  R80 --> DONE(["Phase 8 complete"])
  R82 --> DONE

Release 8.0 is independent of the others and can start earlier than the phase if exposure is a concern. Release 8.2 needs 8.1 (who the staff are) and the audit log. Platform staff can turn on the optional MFA from Release 6.1.