Zero Trust Architecture
Every request is authenticated and authorized. No implicit trust. No trusted networks.
Drok operates on a zero-trust security model. No network is trusted. No service is trusted. No request is trusted. Every interaction — whether from a user, a pipeline, a webhook, or an internal service — is authenticated, authorized, and logged.
Principles
Verify Explicitly
Every API request requires authentication. There are no anonymous endpoints except public repository read access and the landing page. Authentication is verified on every request — not once per session.
Least Privilege Access
Users, services, and pipelines receive the minimum permissions required for their function. Default permissions are restrictive. Escalation requires explicit grant.
Assume Breach
The architecture assumes that any individual component may be compromised. Defense is layered so that the compromise of one component does not cascade to others.
Network Architecture
Service Isolation
Drok's backend services communicate over mTLS (mutual TLS). Each service has a unique identity certificate issued by Drok's internal certificate authority.
- No shared secrets — Services do not share authentication credentials
- Certificate rotation — Service certificates are rotated automatically every 24 hours
- Network segmentation — Services can only communicate with explicitly allowed peers
Pipeline Sandboxing
Pipeline execution environments are fully isolated:
- Ephemeral containers — Each pipeline run executes in a fresh container that is destroyed after completion
- No host access — Pipeline containers cannot access the host system
- Network policy — Outbound network access is restricted to explicitly declared endpoints
- Resource limits — CPU, memory, and disk are bounded per pipeline step
- No inter-pipeline communication — Pipeline runs cannot communicate with other pipeline runs
Third-Party Integration Sandboxing
Third-party integrations run in sandboxed environments:
- Isolated execution — Each integration runs in its own container
- Scoped API access — Integrations receive tokens scoped to the minimum required permissions
- Network restrictions — Integrations can only access declared external endpoints
- Audit logging — All integration actions are logged
- Revocable access — Integration access can be revoked instantly
Authentication Layers
| Layer | Mechanism |
|---|---|
| User to Drok | OAuth 2.0 / SAML 2.0 / OIDC / PAT |
| CLI to Drok | Token stored in system keychain |
| Pipeline to Drok | Short-lived, scoped JWT |
| Service to service | mTLS with auto-rotated certificates |
| Webhook delivery | HMAC-SHA256 signed payloads |
| Git operations | SSH key or HTTPS token |
Secret Management
Pipeline Secrets
- Encrypted at rest with AES-256-GCM
- Injected as environment variables at runtime
- Masked in logs — any output matching a secret value is replaced
- Scoped to specific branches and environments
- Rotation tracked in audit log
Application Secrets
Drok does not store your application secrets. Pipeline secrets are for CI/CD use only. For application secret management, integrate with your preferred secret manager (HashiCorp Vault, AWS Secrets Manager, etc.) from within your pipeline.
Rate Limiting
All API endpoints are rate-limited to prevent abuse:
| Endpoint Category | Rate Limit |
|---|---|
| Authentication | 10 requests/minute |
| API (authenticated) | 5,000 requests/hour |
| API (unauthenticated) | 60 requests/hour |
| Git operations | 1,000 operations/hour |
| Search | 30 requests/minute |
Rate limit headers are included in every response:
X-RateLimit-Limit: 5000
X-RateLimit-Remaining: 4998
X-RateLimit-Reset: 1710523200See Rate Limiting for details.
Security Monitoring
Anomaly Detection
Drok monitors for anomalous behavior patterns:
- Unusual login locations or times
- Bulk repository cloning
- Rapid permission changes
- Unusual API access patterns
Anomalies trigger alerts to organization administrators and are logged in the audit log.
Incident Response
Security incidents are handled according to severity:
- Detection — Automated monitoring identifies the anomaly
- Containment — Affected accounts or services are isolated
- Investigation — Root cause analysis with full audit trail
- Remediation — Vulnerability patched, access restored
- Communication — Affected organizations notified with timeline and impact assessment