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.

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.

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
• Security hardening checklist
• Secrets management
• Security groups concepts
• Server-side encryption
• Compliance and certifications