README

07 — Access Control

SSH key management, OAuth tokens, role assignments, and least-privilege posture across all servers, SaaS, and CI/CD pipelines.

Access is split into three layers: SSH key pairs (server access), OAuth / API tokens (SaaS and service access), and Supabase RLS policies (database row-level access).

Key Documents

Document	Description
elements.md	Credentials section — lists which key/token is used per element
google-oauth-n8n.md	Google OAuth setup for n8n (Gmail, Drive, Calendar)
ssh-hardening-operations.md	SSH hardening procedures, key rotation, authorized_keys management
09-ssh-hardening.md	SSH hardening improvement proposal

SSH Key Inventory

Key name	Location	Used for
id_ed25519 (human)	C:\Users\konar\.ssh\	Root access to all servers, bms-1–4, vps-i1, vps-h1
VPS_SSH_PRIVATE_KEY	GH Secret	claude-admin on vps-i1 (CI/CD + AI agents)
VPS_ROOT_SSH_KEY	GH Secret (base64)	Root provisioning workflow
radieu-root-2026-05-15	bms-1:/root/.ssh/authorized_keys	Root on bms-1

User / Role Matrix

Server	Human user	CI/CD user	Claude agent user
vps-i1	root	claude-admin	AI-Dev-IO1
vps-h1	root	—	AI-Dev-HS1
bms-1	root	—	—
bms-2	ubuntu / claude-admin	—	—
bms-3	ubuntu	—	—
bms-4	root	—	AI-Dev-BMS4-1

Supabase Roles

Role	Permissions
service_role	Full access (backend only)
grafana_readonly	SELECT on monitoring/fleet tables
anon	SELECT/INSERT on dev_r_* tables (DevOps tooling — public via RLS policies)

Cross-references

• README — API keys, tokens, and Infisical vault
• README — SSH hardening, firewall rules, CVE exposure