SecurityZero Trust

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

LayerMechanism
User to DrokOAuth 2.0 / SAML 2.0 / OIDC / PAT
CLI to DrokToken stored in system keychain
Pipeline to DrokShort-lived, scoped JWT
Service to servicemTLS with auto-rotated certificates
Webhook deliveryHMAC-SHA256 signed payloads
Git operationsSSH 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 CategoryRate Limit
Authentication10 requests/minute
API (authenticated)5,000 requests/hour
API (unauthenticated)60 requests/hour
Git operations1,000 operations/hour
Search30 requests/minute

Rate limit headers are included in every response:

X-RateLimit-Limit: 5000
X-RateLimit-Remaining: 4998
X-RateLimit-Reset: 1710523200

See 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:

  1. Detection — Automated monitoring identifies the anomaly
  2. Containment — Affected accounts or services are isolated
  3. Investigation — Root cause analysis with full audit trail
  4. Remediation — Vulnerability patched, access restored
  5. Communication — Affected organizations notified with timeline and impact assessment