Identity-based access. Every cloud.
Crab Auth connects your corporate identity provider to your cloud storage. Developers authenticate once via SSO — the system handles credential vending, RBAC enforcement, and automatic rotation. No shared keys, no manual setup.
From Solo Developer to Enterprise Team
Individual developers use their existing cloud credentials directly. Teams add centralized identity and access control through the credential vending service.
Crab Auth Flow
From SSO sign-in to scoped cloud credentials — fully automatic.
Four Steps to Secure Access
The credential vending protocol in action.
Inside crab-auth
Three-stage pipeline: verify the token, evaluate the policy, mint the credential.
Declarative RBAC Policies
Define who can access which repositories and what operations they can perform. Policies are evaluated top-to-bottom with deny rules checked first. Supports identity matching by email, group membership, and glob patterns for repository paths.
- Deny rules evaluated before allow rules
- Match by email identity or IdP group membership
- Glob patterns for repo paths (models/*, datasets/*)
- Per-rule provider override (route repos to different clouds)
Works With Your Identity Provider
Any OIDC-compliant IdP with a standard discovery endpoint.
Deploy Anywhere
crab-auth is a stateless FastAPI service. Pick the deployment model that fits your infrastructure.
Auth Methods by Cloud Provider
Full compatibility matrix across AWS, GCP, and Azure.
| Feature | AWS | GCP | Azure |
|---|---|---|---|
| IAM Roles / Instance Profiles | |||
| Service Accounts / Workload Identity | |||
| Managed Identities | |||
| Environment Variables | |||
| Config File Profiles | |||
| Instance Metadata | |||
| Credential Chain (auto-resolve) | |||
| Enterprise Credential Vending |
Compared to Shared Keys and LFS Servers
Identity-based credential vending eliminates the security gaps of shared IAM keys and the operational burden of LFS servers.
| Feature | Crab Auth (Enterprise) | Shared IAM Keys | Git LFS + Server |
|---|---|---|---|
| No shared secrets | |||
| Per-repo access control | Server-dependent | ||
| Short-lived credentials | |||
| SSO / OIDC integration | Server-dependent | ||
| Audit trail (who accessed what) | Server-dependent | ||
| No server to manage | Stateless container or Lambda | ||
| Multi-cloud (AWS, GCP, Azure) | One provider at a time | ||
| Automatic credential rotation |
Defense in Depth
Every layer of the auth pipeline is designed to minimize blast radius and prevent credential leakage.
Cryptographic Verification
JWT signatures verified against IdP JWKS (RS256/ES256). Invalid, expired, or tampered tokens are rejected with 401.
Scoped Session Policies
AWS credentials use inline session policies intersected with the base role. Vended credentials can never exceed the requested repo prefix.
No Secrets in Logs
Token values are never logged. Only identity (email/sub) and operation metadata appear in structured log output.
Rate Limiting
Built-in token bucket rate limiter prevents credential enumeration and brute-force attacks against the endpoint.
Claims Validation
Issuer (iss), audience (aud), expiration (exp), and not-before (nbf) claims are all verified on every request.
Stateless Architecture
No database, no session store. The service can be restarted, scaled, or replaced without data loss or state corruption.
Frequently Asked Questions
Common questions about Crab Auth and credential vending.
Does crab-auth store my data?
What happens if crab-auth goes down?
Can I use crab-auth with multiple cloud providers?
How are credentials scoped?
What IdPs are supported?
Do I need crab-auth for personal use?
Secure your team's repositories.
Deploy crab-auth in your VPC and give every developer identity-based access to cloud storage — no shared keys, no manual rotation.