Overview
OpsWorker's security architecture is built on the principles of least privilege, defense in depth, and human oversight.
Security Architecture
Agent Security
| Control | Implementation |
|---|
| Read-only access | Agent only performs get/list/watch operations |
| Outbound-only communication | No inbound ports; agent polls SQS |
| No stored credentials | Cluster token only; no kubeconfig in cloud |
| Scoped RBAC | Configurable permissions, namespace restrictions |
| Minimal footprint | Single pod, no DaemonSets or sidecars |
Cloud Security
| Control | Implementation |
|---|
| Serverless | No servers to patch or manage |
| Multi-tenant isolation | Organization-level data partitioning |
| Encryption | At rest (AES-256) and in transit (TLS 1.2+) |
| Access control | Role-based access in portal (Admin/Member) |
| Audit logging | Investigation activities logged |
Application Security
| Control | Implementation |
|---|
| Authentication | SSO (Google, Azure AD), email/password with MFA |
| Authorization | Role-based access control |
| Session management | Secure session handling via Auth0 |
| API security | Authenticated API endpoints |
Human Oversight
OpsWorker never auto-executes commands on your cluster:
- Recommendations are suggestions for human review
- Engineers decide what to execute and when
- The safe execution model ensures humans stay in control
Compliance
| Standard | Status |
|---|
| SOC 2 | Compliance pathway — contact OpsWorker for details |
| Data residency | AWS region-specific — contact for region options |
| GDPR | Data processing aligned with GDPR requirements |
For specific compliance questions or security documentation requests, contact the OpsWorker team.
Next Steps