Skip to main content
Uses direct grants instead of roles because it needs a mix of read and write on specific tables.
CREATE USER IF NOT EXISTS frontline IDENTIFIED WITH sha256_password BY '<password>';

-- Read access to verification aggregation tables
GRANT SELECT ON default.key_verifications_per_day_v3 TO frontline;
GRANT SELECT ON default.key_verifications_per_hour_v3 TO frontline;
GRANT SELECT ON default.key_verifications_per_minute_v3 TO frontline;
GRANT SELECT ON default.key_verifications_per_month_v3 TO frontline;

-- Read + write access to raw verifications
GRANT SELECT, INSERT ON default.key_verifications_raw_v2 TO frontline;

-- Write access to the key-last-used MV target
-- (the MV trigger runs in the inserting user's context and writes here)
GRANT SELECT ON default.key_last_used_v1 TO frontline;


-- Read + write access to raw frontline requests
GRANT SELECT, INSERT ON default.frontline_requests_raw_v1 TO frontline;

-- Frontline request rollup cascade: raw -> per_minute -> per_5m -> per_15m -> per_hour -> per_day.
-- The MVs trigger in the inserting user's context, and each one reads its source table
-- (SELECT) and writes its target table, so frontline needs SELECT on every level.
GRANT SELECT ON default.frontline_requests_per_minute_v1 TO frontline;
GRANT SELECT ON default.frontline_requests_per_5m_v1 TO frontline;
GRANT SELECT ON default.frontline_requests_per_15m_v1 TO frontline;
GRANT SELECT ON default.frontline_requests_per_hour_v1 TO frontline;
GRANT SELECT ON default.frontline_requests_per_day_v1 TO frontline;