Data Isolation & Encryption
Overview
OpsWorker is a multi-tenant platform that uses logical, application-layer isolation between organizations and encryption for data at rest and in transit.
Tenant Isolation
Organization-Level Separation
Tenant isolation is logical and enforced at the application layer on shared DynamoDB tables. Data is not separated into physically distinct partitions or accounts per organization.
- Investigation data, signals, and configurations are keyed by organization
- Application-layer access controls scope every query to the requesting organization
- Each organization has its own cluster tokens, integrations, and user accounts
Workspace Separation
Within an organization, workspaces provide additional separation:
- Users only see data from workspaces they're assigned to
- Admin users can see all workspaces within their organization
Encryption
At Rest
| Data Store | Encryption |
|---|---|
| Investigation data (DynamoDB) | AWS-managed encryption (AES-256) |
| Investigation artifacts (S3) | AWS-managed encryption (AES-256) |
| Configuration data | AWS-managed encryption |
In Transit
All network traffic is encrypted with TLS using AWS defaults. The protocol version is not pinned to a specific minimum (such as TLS 1.2+) by configuration.
| Communication Path | Encryption |
|---|---|
| Alert webhooks → API Gateway | TLS (AWS default) |
| Agent ↔ SQS | TLS (AWS default) |
| Portal ↔ API | TLS (AWS default) |
| Internal service communication | TLS within AWS |
Credential Handling
- No cluster credentials stored: OpsWorker doesn't have SSH keys, kubeconfig, or cloud provider credentials for your clusters
- Cluster tokens: Used only for agent authentication; not Kubernetes credentials
- Integration tokens: Stored encrypted (Slack OAuth, GitHub tokens, Datadog API keys)
Next Steps
- Security & Compliance: Broader security architecture
- Agent Scope: What data leaves your cluster