# Shared responsibility model

Source: https://docs.quake.ai/docs/security/shared-responsibility
Markdown: https://docs.quake.ai/docs/security/shared-responsibility.md

---

# Shared responsibility model

Security on Quake AI is a partnership between the platform and you. Quake AI secures the infrastructure that runs all services: physical hardware, hypervisors, network backbone, and the control plane APIs. You secure everything you build on top of that infrastructure: your instances, applications, data, credentials, and access policies.

This division exists because the platform cannot make assumptions about your workloads. A permissive security group that allows all inbound traffic might be intentional for a public web server or a misconfiguration that exposes a database. You define the intent, so you enforce the right controls.

The boundary is consistent for each service: Quake AI provides secure defaults and the tools to configure access, encryption, and networking. You use those tools to lock down your specific environment.

<Figure size="lg" caption="Shared responsibility boundary: you manage what runs on the platform, Quake AI manages everything underneath. The full split lives in the table below.">

```d2
direction: down

you: You manage {
  apps: Applications + data
  creds: Credentials + secrets
  config: Security groups + OS patches
}

platform: Quake AI manages {
  api: API auth + control plane
  hyper: Hypervisor isolation
  infra: Physical infra + backbone
}

you -> platform: responsibility boundary {
  style.stroke-dash: 5
  style.stroke-width: 3
}
```

</Figure>

## What the platform secures

Quake AI is responsible for:

- **Physical infrastructure**: datacenter access controls, hardware lifecycle management, disk destruction on decommission
- **Hypervisor isolation**: tenant workloads run on isolated virtual machines; no cross-tenant memory or storage access
- **Network backbone**: core switching, routing, and DDoS mitigation at the infrastructure layer
- **API authentication**: Keystone identity service enforces token-based authentication for all control plane operations
- **Service availability**: redundant control plane services, automated failover, and infrastructure monitoring

You do not need to manage, patch, or monitor any of these layers. Quake AI applies platform-side security updates without customer action.

## What you secure

You are responsible for:

- **Security groups**: firewall rules that control inbound and outbound traffic to your instances. The default security group blocks all inbound traffic; you open only the ports your workloads require.
- **SSH key pairs**: authentication credentials for accessing your instances. You generate, store, and rotate your private keys.
- **Application code and dependencies**: vulnerabilities in your software, libraries, and container images are yours to patch.
- **Data encryption at rest**: object storage supports SSE-C (customer-provided keys) and SSE-OMK (operator-managed keys). You choose which objects to encrypt and manage your SSE-C keys.
- **Bucket policies**: access control policies on object storage containers that determine who can read, write, or list objects.
- **Operating system patching**: your instances run the OS image you select. You are responsible for applying security updates after launch.
- **Secrets management**: API credentials, application secrets, S3 access keys, and database passwords. You generate, store, rotate, and revoke these credentials.
- **Network architecture**: choosing between public and private networks, configuring routers, and minimizing public exposure through floating IP management.

## Responsibility by service area

The table below summarizes the split per service area. For detailed guidance on each customer responsibility, see the bullets above.

| Area | Platform responsibility | Customer responsibility |
|---|---|---|
| **Compute** | Hypervisor isolation, host patching, hardware reliability | OS patching, security groups, key pair management, application security |
| **Network** | Core routing, backbone integrity, external connectivity | Security group rules, floating IP allocation, private network design, certificate management |
| **Object Storage** | Storage cluster availability, data durability, replication | Bucket policies, SSE-C key management, access credential rotation, public access settings |
| **Block Storage** | Volume availability, snapshot infrastructure, NVMe hardware | Volume encryption decisions, snapshot lifecycle, access via instance security |
| **Kubernetes** | Control plane availability, master node maintenance, cluster provisioning, node image base, networking setup, load balancer provisioning, cluster upgrade execution | Workload RBAC, pod security policies, image scanning, cluster upgrade scheduling |

## Secure defaults

Quake AI ships with secure defaults designed to prevent accidental exposure:

- **Default security group** blocks all inbound traffic and allows all outbound traffic. You must explicitly open ports.
- **Instances launch on private networks** unless you specifically attach them to `PublicEphemeral` or assign a floating IP.
- **Object storage containers are private** by default. Public read access requires an explicit ACL or bucket policy.
- **S3 credentials are separate** from OpenStack app credentials. Generating S3 credentials is an explicit opt-in action.

These defaults mean a newly created resource has minimal attack surface. You expand access as needed instead of restricting from an open default.

## See also

- [Security overview](/docs/security)
- [Security hardening checklist](/docs/security/hardening-checklist)
- [Secrets management](/docs/security/secrets-management)
- [Security groups concepts](/docs/network/concepts/security-groups)
- [Server-side encryption](/docs/object/how-to/configure-server-side-encryption)
- [Compliance and certifications](/docs/security/compliance-and-certifications)