Skip to content

Commit 999474e

Browse files
committed
add new security docs page
1 parent ab4df0f commit 999474e

3 files changed

Lines changed: 49 additions & 0 deletions

File tree

Lines changed: 47 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,47 @@
1+
# Security Overview
2+
3+
4+
At Tobiko, we treat security as a first class citizen because we know how valuable your data assets are. Our team follows and executes security best practices across each layer of our product.
5+
6+
## Tobiko Cloud Standard Deployment
7+
8+
Our standard Tobiko Cloud deployment consists of several componenets that are each responbisble for different parts of the product.
9+
10+
Below is a diagram of the components along with their description.
11+
12+
![tobiko_cloud_standard_deployment](./tcloud_standard_deployment.png){ width=80% height=60% style="display: block; margin: 0 auto" }
13+
14+
- **Scheduler**: Orchestrates schedule cadence and hosts state metadata(code versions, logs, cost)
15+
- **Executor**: Applies code changes and runs SQL queries (actual data processing in SQL Engine) and python models in proper DAG order.
16+
- **Gateway**: Stores authentication to SQL Engine. Secured through encryption.
17+
- **SQL Engine**: Processes and stores data based on the above instructions within the **customer’s** environment.
18+
19+
## Internal Code Practices
20+
21+
Our coding standards are guidelines we enforce throughout the organization to write, maintain, and collaborate on code effecively. These practice ensure consistency, maintainability, realibility, and most importantly, trust.
22+
23+
Below you will find a few examples of our interal code requirements.
24+
25+
- We have signed commits, required approvers, and signed docker artifacts.
26+
- Each commit to main is approved by someone different than the author.
27+
- We follow the standard of signing commits and then registering the key with GitHub. [Github Docs](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits)
28+
- Binary is signed using cosign and OIDC for keyless. [Signing docs](https://docs.sigstore.dev/cosign/signing/overview/)
29+
30+
31+
## Physical Property
32+
33+
### How do we protect PGP keys?
34+
35+
If an employee loses their laptop, we don't need to get the old PGP key back. We use GitHub to sign code. At the time the code was committed, the PGP key was valid. When an employee loses their laptop, we will invalidate it, and they will regenerate a new key. The old commits are valid because the PGP key was valid at the time.
36+
37+
### How do we invalidate PGP keys if someone did steal it and could potentially use it?
38+
39+
Revoke access for the GitHub user account associated with the compromised key and not give them access again until the old PGP key is deprecated and issue a new PGP key.
40+
41+
### If someone steals a laptop, what's our continuity plan in protecting code?
42+
43+
- All employee devices are monitored for appropriate encryption and password policies
44+
- Laptop protection is done through file encryption for Vanta
45+
- Mandatory lock screen after a timeout
46+
- We have a procedure for the disposal of an IT asset to mitigate keys being compromised through inappropriate disposal
47+
- See above for PGP key protection
89.7 KB
Loading

mkdocs.yml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -123,6 +123,8 @@ nav:
123123
- "Docker Compose example": cloud/features/scheduler/hybrid_executors_docker_compose.md
124124
- cloud/features/scheduler/airflow.md
125125
- cloud/features/scheduler/dagster.md
126+
- Security:
127+
- "Security Overview": cloud/features/security/security.md
126128
# - Observability:
127129
# - cloud/features/observability/overview.md
128130
# - cloud/features/observability/model_freshness.md

0 commit comments

Comments
 (0)