SAT Sovereign Authority & Operator Identity

The Aarkam Standalone Tier (SAT) implements a strict Zero-Trust Control Plane Architecture engineered for air-gapped defense grids, banking clusters, and high-assurance sovereign clouds. In SAT, the storage cluster itself is the sovereign trust authority: every administrative mutation, disk evacuation, or bucket policy change is cryptographically validated directly by the Rokka Coordinator MON Quorum over gRPC mTLS (ports 7774 / 57774).

1. Zero-Trust Architecture Principles

2. Three-Tier Identity Hierarchy

The SAT storage fabric strictly partitions identities into three decoupled tiers to guarantee the principle of least privilege:

3. Native Persistence in KdoujaKV & Raft Quorum

Unlike traditional storage platforms that require external SQL servers or relational databases to hold credentials, SAT stores operator identities directly inside the Rokka Raft Consensus State Machine and KdoujaKV LSM-Tree:

1. Raft Distributed Consensus: Any user provisioning, credential rotation, role assignment, or account lock is submitted as an append-only transaction replicated across the 3 or 5 MON Coordinator nodes via RaftConsensusEngine.
2. Encrypted KdoujaKV LSM Storage: Once consensus is reached, user state is committed to KdoujaKV with hardware AES-256-GCM write-ahead log encryption (WalEncryptionKey), ensuring instant recovery across node reboots.
3. In-Process L1 Auth Cache: Operator token lookups and permission evaluations complete in <50 nanoseconds via an in-memory lock-free concurrent cache, eliminating any need for Redis or external cache daemons.

Internal Key Schema in KdoujaKV

usr:ident:<user_id>       -> Complete UserRecord (Argon2id hash, roles, tenant, epoch)
usr:name:<username>       -> Secondary index pointing to <user_id>
usr:s3key:<access_key_id> -> S3CredentialRecord (Hashed secret key, bound tenant ID, IAM policy)

4. Cryptographic Credential Hygiene

4.1 Argon2id Password Hashing

Passwords stored in SAT are hashed using Argon2id (RFC 9106), the most secure memory-hard password derivation function against GPU and ASIC brute-force attacks:

• Memory Size: 65,536 KiB (64 MB)
• Iterations (Time Cost): 3 passes
• Parallelism: 4 threads
• Salt: 256-bit cryptographically secure random bytes generated via OS CSPRNG

4.2 Local Credential Caching (DPAPI & POSIX 0600)

When an operator runs am auth login, the generated session token is cached securely on the local workstation:

• Windows Server / Windows 11: Encrypted using Windows DPAPI (Data Protection API) bound to the active user's SID (stored at %LOCALAPPDATA%\Aarkam\am_auth.dat or credentials.json).
• Linux (Ubuntu / RHEL): Written to ~/.aarkam/am_auth.dat or ~/.rokka/credentials.json with strict POSIX 0600 permissions (readable and writable only by the invoking user account).

5. Operator Authentication Commands (am auth)

5.1 Authenticate Operator Session (am auth login)

# Interactive prompt for password
am auth login --username secadmin

# Programmatic login for CI/CD pipelines
am auth login --username storage-bot --password-env BOT_SECRET --non-interactive

5.2 Inspect Active Session Claims (am auth whoami & am auth status)

am auth whoami
# Output: secadmin (tenant: system, roles: [ClusterAdmin, SecurityOfficer])

am auth status
# Output: Token valid, expires in 4 hours 12 minutes (Issuer: Rokka.Coordinator)

5.3 Revoke and Clear Credentials (am auth logout)

am auth logout
# Clears local DPAPI / POSIX 0600 token cache securely

6. Break-Glass Emergency Root Administration

If the entire operator roster is locked or in the event of an offline disaster recovery procedure, SAT supports local break-glass emergency access:

• Physical Access Required: Break-glass administration requires root shell access directly on an active Raft Coordinator node.
• Local Master X.509 Certificate: The operator presents the offline master cluster certificate (generated during the Genesis Ceremony):

  am cluster doctor --client-cert /etc/aarkam/certs/master-admin.pfx --cert-password-env MASTER_CERT_PASS

• Emergency Account Unlock: The operator resets credentials directly through the local Coordinator IPC channel without requiring network egress or external validation.