Security hardening checklist

Use this checklist to audit and harden your Quake AI project. Each item links to the relevant documentation for implementation details. Work through the sections in order: project-level controls protect all resources, then per-service hardening locks down individual workloads.

Project-level hardening#

• Review the default security group. The default group blocks all inbound and allows all outbound traffic. Confirm that no one has added permissive inbound rules to it. See security groups concepts.
• Use dedicated security groups per workload. Create separate security groups for each application tier (web, app, database) rather than adding all rules to the default group. See create a security group.
• Rotate SSH key pairs. Generate new key pairs periodically and remove old public keys from instances. See key pairs concepts.
• Rotate app credentials. Regenerate your openrc.sh credentials and S3 access keys on a regular schedule. See generate app credentials and create S3 credentials.
• Enable two-factor authentication. Protect your portal account with 2FA. See your account.

Compute hardening#

• Use SSH key authentication only. Disable password-based SSH access on your instances. Quake AI images default to key-only authentication; verify this remains set after any configuration changes.
• Apply OS security updates. Run sudo apt update && sudo apt upgrade (Ubuntu/Debian) or sudo dnf update (Rocky/Fedora) after instance launch and on a regular schedule.
• Restrict security group rules to least privilege. Open only the ports your application requires. Avoid 0.0.0.0/0 on non-public ports. See create security group rules.
• Disable unused services. Remove or stop services you do not need (e.g., mail agents, FTP daemons) to reduce your attack surface.
• Use cloud-init for consistent hardening. Automate security configuration at launch (package updates, SSH hardening, firewall rules) using cloud-init user-data or infrastructure as code templates. See IaC templates.

Network hardening#

• Audit security group rules on a schedule. List all rules with openstack security group rule list and remove overly broad entries. See security groups CLI reference.
• Minimize floating IP usage. Assign floating IPs only to instances that require direct public access. Use private networks with a bastion host or reverse proxy for internal services. See allocate floating IPs.
• Use private networks for internal communication. Place application tiers on private networks and route external traffic through an edge reverse proxy. See create a network.
• Use TLS certificates for public endpoints. Terminate TLS at your application server, reverse proxy, CDN, or WAF. See issue and auto-renew a TLS certificate and the edge reverse proxy template.
• Front public HTTP workloads with a WAF when appropriate. Filter attack traffic before it reaches app instances. See front with a WAF.

Storage hardening#

• Set bucket policies on every container. Do not rely on the default private ACL alone: write explicit bucket policies that define who can access what. See grant access control.
• Encrypt sensitive objects with SSE-C. Use server-side encryption with customer-provided keys for confidential data. See server-side encryption.
• Rotate S3 credentials. Delete old EC2 credential pairs and generate new ones periodically. See create S3 credentials.
• Enable bucket versioning for critical data. Versioning protects against accidental overwrites and deletions. See enable versioning.
• Restrict public read access. Review containers with public ACLs (X-Container-Read: .r:*) and remove public access where it is no longer needed.

Monitoring and operations#

• Review access logs. Check instance auth.log and syslog for unauthorized access attempts.
• Monitor resource quotas. Unexpected quota usage may indicate compromised credentials creating unauthorized resources. See resource tiers.
• Audit API token usage. Review active tokens and revoke any that are no longer needed. See API tokens.
• Maintain an inventory of public endpoints. Track which floating IPs are assigned, which containers are publicly readable, and which security groups allow inbound traffic from 0.0.0.0/0.

See also#

• Shared responsibility model
• Secrets management
• Security overview