Authentication
Google Workspace OAuth 2.0 with PKCE flow, domain restrictions, and secure session management.
Security Overview
Rack Gateway was designed from the ground up with security and compliance in mind. This section covers the security architecture, access controls, and compliance features.
Security Architecture
Section titled “Security Architecture”Rack Gateway provides multiple layers of security:
Security Features
Section titled “Security Features”RBAC
Four hierarchical roles for people and a CI/CD role for API tokens, with granular permissions and per-permission MFA requirements.
Audit Logging
Immutable audit trail with automatic secret redaction and optional S3 WORM storage.
Compliance
Built for SOC 2 compliance with proper access controls, logging, and data retention.
Key Security Principles
Section titled “Key Security Principles”Defense in Depth
Section titled “Defense in Depth”Multiple independent security controls ensure that a failure in one layer doesn’t compromise the system:
| Layer | Protection | If Bypassed |
|---|---|---|
| Network | Private network access | Authentication blocks |
| Authentication | OAuth + session tokens | MFA blocks |
| MFA | Second factor verification | RBAC limits scope |
| RBAC | Permission restrictions | Audit logs provide evidence |
| Audit | Complete activity record | Forensic investigation |
Least Privilege
Section titled “Least Privilege”Users receive only the permissions they need:
- Viewer: Read-only access to non-sensitive data
- Ops: Operational access without deployment capabilities
- Deployer: Deployment access without administrative powers
- Admin: Full access for administrators only
- CI/CD: API tokens that request deploy approvals and deploy once approved
Secure Defaults
Section titled “Secure Defaults”Rack Gateway ships with secure defaults:
- MFA required for every user
- Sessions expire after inactivity
- HTTPS required in production
- Env var values redacted from audit logs unless an app lists them as visible
- Nothing happens unless its audit entry was written first
- CSRF protection, a strict Content Security Policy and secure cookies
- Test-only bypasses compiled out of the published image
Threat Model
Section titled “Threat Model”Rack Gateway protects against common threats:
| Threat | Protection |
|---|---|
| Credential theft | OAuth (no passwords stored), MFA |
| Session hijacking | Secure cookies, session validation |
| Privilege escalation | Strict RBAC enforcement |
| Insider threats | Audit logging, RBAC separation |
| Token leakage | Short-lived sessions, API token scoping |
| Replay attacks | Token validation, session tracking |
| Man-in-the-middle | HTTPS to the gateway; the gateway reaches the rack API over the rack’s private network |
Security Sections
Section titled “Security Sections”- Overview - RBAC concepts and design
- Roles - Role definitions and capabilities
- Permissions - Complete permission reference
- Best Practices - RBAC implementation patterns
- Overview - Authentication architecture
- OAuth Flow - OAuth 2.0 + PKCE details
- Sessions - Session management
- API Tokens - Token security
- Overview - Compliance framework
- SOC 2 - SOC 2 alignment guide
- Audit Trail - Audit logging details
- Data Retention - Retention policies
Best practices for hardening your Rack Gateway deployment.
Security Checklist
Section titled “Security Checklist”Before going to production, verify:
- HTTPS configured with valid certificates
- Gateway on private network (Tailscale/VPN recommended)
- Google OAuth configured with domain restrictions
- MFA enforcement enabled for all users
- Audit logging configured with S3 WORM storage
- Session timeout configured appropriately
- API tokens scoped with minimal permissions
- Protected environment variables configured
- Security notifications enabled
- Regular access reviews scheduled
See Production Checklist for complete deployment verification.
Reporting Security Issues
Section titled “Reporting Security Issues”If you discover a security vulnerability in Rack Gateway:
- Do not open a public GitHub issue
- Report it privately: report a vulnerability on GitHub, or email security@docspring.com
- Include the version, what an attacker can do, and steps that reproduce it
- Allow time for a fix before public disclosure
Only the latest release gets security fixes. See the repository’s security policy for details. We credit reporters in the release notes.