shawnschwartz/tinyvault repository overview

⁠🔐 TinyVault

DIY Google Workspace encryption for ~$0.10/month

GitHub Repo: https://github.com/shawntz/tinyvault⁠

⁠💡 What is TinyVault?

TinyVault is a lightweight, self-hosted KACLS endpoint for Google Workspace Client-Side Encryption (CSE). It enables you to encrypt Gmail, Drive, Calendar, and Meet content with your own encryption keys—without paying thousands of dollars for enterprise CSE partner solutions.

Best for: Personal use, small teams, learning, non-critical data NOT for: HIPAA/PCI/regulated data (without your own compliance work), mission-critical enterprise use (without hardening)

⁠The Problem

Google Workspace CSE requires a third-party key service. Google's official partners charge:

• $10-30 per user/month minimum
• Enterprise-only pricing (often 50+ user minimums)
• Annual contracts starting at $6,000+

For individuals or small teams, this is prohibitively expensive.

⁠The Solution

TinyVault lets you run your own CSE endpoint for ~$0.10-0.50/month using:

• Google Cloud Run (serverless, free tier available)
• Google Cloud KMS (secure key storage, FIPS 140-2 validated)
• Your own infrastructure and control

⁠✨ Features

• 🔒 Secure: Uses Google Cloud KMS for key management (FIPS 140-2 validated)
• 💰 Cheap: Runs in Cloud Run free tier (~$0.10-0.50/month for single user)
• 🚀 Simple: Deploy in under 5 minutes with automated scripts
• 🌐 Custom Domains: Professional setup with your own domain
• 🐳 Docker Ready: Pre-built containers on Docker Hub
• 📝 Well Documented: Comprehensive guides and troubleshooting
• 🔓 Open Source: MIT licensed, contribute and customize freely

⁠Run Locally with Docker

# Pull the image
docker pull shawnschwartz/tinyvault:latest

# Run with your configuration
docker run -d \
  -p 8080:8080 \
  -e GCP_PROJECT_ID=your-project \
  -e KMS_LOCATION=us-central1 \
  -e KMS_KEYRING=cse-keyring \
  -e KMS_KEY=cse-key \
  -e [email protected] \
  -v /path/to/service-account.json:/app/key.json \
  -e GOOGLE_APPLICATION_CREDENTIALS=/app/key.json \
  --name tinyvault \
  shawnschwartz/tinyvault:latest

⁠🔒 Security

⁠Security Maturity Level

Current Status: ⚠️ Prototype / Personal Use

TinyVault is:

• ❌ NOT security audited by third-party professionals
• ❌ NOT penetration tested
• ❌ NOT certified for any compliance framework (HIPAA, PCI, FedRAMP, SOC 2, etc.)
• ❌ NOT recommended for production enterprise use without significant hardening
• ❌ NOT a replacement for professionally audited enterprise CSE solutions

TinyVault IS:

• ✅ Good for: Personal use, learning, experimentation, non-critical data
• ✅ Open source: Code is transparent and auditable (by you or security professionals you hire)
• ✅ Based on secure components: Uses Google Cloud KMS and Cloud Run

If you need compliance certification, you are responsible for:

• Hiring security auditors
• Penetration testing
• Code review
• Compliance documentation
• Risk assessment
• Incident response planning

⁠What IS Secure (Google Cloud Components)

The underlying Google Cloud infrastructure TinyVault uses:

Google Cloud KMS (where keys are stored):

• ✅ FIPS 140-2 Level 3 validated hardware security modules
• ✅ ISO/IEC 27001 certified
• ✅ SOC 2/3 compliant
• ✅ HIPAA eligible (with BAA)
• ✅ PCI DSS compliant

Google Cloud Run (where TinyVault runs):

• ✅ HTTPS enforced (TLS 1.2+)
• ✅ Automatic SSL certificates
• ✅ ISO 27001, SOC 2/3 certified
• ✅ Infrastructure security managed by Google

⁠What IS NOT Secure (TinyVault Application)

TinyVault application code:

• ⚠️ No professional security audit
• ⚠️ No penetration testing
• ⚠️ No formal threat modeling
• ⚠️ No security certifications
• ⚠️ Minimal input validation
• ⚠️ No rate limiting by default
• ⚠️ No WAF (Web Application Firewall) by default
• ⚠️ Unauthenticated Cloud Run endpoint (by design for KACLS protocol)

⁠Security Architecture

What's good:

• ✅ Master encryption keys never leave Google Cloud KMS (FIPS 140-2 validated HSMs)
• ✅ Keys are never exposed to the application or stored anywhere except KMS
• ✅ OAuth2 token verification for incoming requests
• ✅ Email-based authorization (restrict to specific users)
• ✅ All KMS operations logged via Cloud Audit Logs
• ✅ HTTPS-only connections enforced by Cloud Run
• ✅ Encrypted data at rest (wrapped DEKs stored with encrypted content)

What could be better:

• ⚠️ No rate limiting (could be DDoS'd)
• ⚠️ Cloud Run endpoint is public (required for Google Workspace, but increases attack surface)
• ⚠️ No request signing/validation beyond OAuth2 token
• ⚠️ No anomaly detection
• ⚠️ No intrusion detection
• ⚠️ Minimal monitoring by default

⁠Security Recommendations by Use Case

⁠✅ Personal Use (1-5 people, non-sensitive data)

• Current security is adequate
• Follow the basic security checklist below
• Accept that this is DIY software

⁠⚠️ Small Team (5-20 people, somewhat sensitive data)

• Current security is marginal
• Add: Rate limiting, WAF (Cloud Armor), monitoring alerts
• Consider: Security code review by a professional
• Accept risk: This is not enterprise-grade

⁠❌ Enterprise / Regulated Data (HIPAA, PCI, etc.)

• Current security is insufficient
• Required: Full security audit, penetration testing, compliance documentation
• Required: Hire security professionals to harden
• Recommended: Use a professionally audited CSE partner instead