Credentials and tools

Quake AI gives you multiple ways to prove who you are, and each one fits a different tool and a different job. The console uses an interactive browser session. The OpenStack CLI, SDKs, and automation use application credentials. Quick HTTP calls use a short-lived API token. S3-compatible tools use S3 credentials. Logging in to an instance uses an SSH key. They are separate mechanisms with separate scopes, and picking the right one comes down to matching the credential to what you are trying to reach.

This page explains how the pieces relate. For the procedures that create each credential, follow the links in each section.

The authentication surfaces#

You authenticate against four kinds of credential, plus the interactive console session.

The console session is the interactive surface. You sign in with your Rumble.com account at sky.<region>.rumble.cloud and the browser holds the session. Everything below is for the non-interactive surfaces: tools and scripts that authenticate on their own.

Application credentials authenticate the OpenStack CLI, SDKs, Terraform, and Ansible against the project API. The identity service (OpenStack Keystone) issues them as an ID and secret pair, and they work without your account password. Each credential covers one project and carries one of three coarse Keystone roles (admin, member, reader). You can give a credential an expiration date or restrict it to specific API paths with access rules. This is the right choice for long-lived programmatic access. See the application credentials reference and Generate application credentials.

API tokens authenticate direct HTTP requests. Keystone issues a project-scoped token that lasts 24 hours, and you pass it in the X-Auth-Token header. A token carries the same permissions your user has in the scoped project. Tokens suit quick, ad-hoc calls such as testing an endpoint with curl. For automation, application credentials are the better fit because the CLI renews their tokens for you. See How to get an API token.

S3 credentials authenticate S3-compatible tools against object storage. They are EC2-style access key and secret key pairs tied to your user account, so they work across all your projects rather than within a single one, and they reach object storage only. Use them with the AWS CLI, s3cmd, rclone, boto3, and similar clients, pointed at the regional object storage endpoint (for example object.us-east-1.rumble.cloud). See the S3 credentials reference and How to create S3 credentials.

SSH keys authenticate you to a running instance over SSH. You generate an ed25519 key pair locally, upload the public half to your account under Compute > Key Pairs, and keep the private half on your machine. Quake AI injects the public key into an instance at boot, and the key pair stays associated with your account so it follows you across projects. See Add an SSH key pair to your account.

How credential scope works#

Scope is the practical difference between these credentials. Two cover a single project, and two belong to your user account.

A project-scoped credential reaches only the project that issued it. To limit how much a leaked credential can touch, you separate workloads into different projects and issue each its own credentials, the same boundary described in the account model. User-scoped credentials (S3 credentials and SSH keys) follow your account into every project you can open.

How the OpenStack CLI authenticates#

The openstack command reads its credentials from one of two places, both produced from an application credential.

• clouds.yaml defines one or more named clouds, each with its auth URL, application credential ID, and secret. You select one with --os-cloud or the OS_CLOUD environment variable. This is the recommended setup for the CLI and SDKs.
• openrc.sh is a shell script you download from the credential creation dialog. Sourcing it (source openrc.sh) exports OS_* environment variables into your current shell, and the CLI reads them from the environment.

Either way, the CLI sends the application credential to Keystone, receives a token, and uses that token for the session. You do not handle the token yourself. See Install the OpenStack client and the OpenStack client guide to set this up, and CLI debugging when authentication fails.

Choosing a credential#

Match the credential to the task:

• Running the CLI, an SDK, or Terraform: application credentials.
• One-off HTTP request or endpoint test: an API token.
• Reading or writing object storage with an S3 client: S3 credentials.
• Logging in to an instance: an SSH key.

Related reading#

• Application credentials reference: fields, actions, and access rules
• Generate application credentials: create credentials and configure clouds.yaml
• How to get an API token: project-scoped tokens for HTTP requests
• S3 credentials reference: EC2-compatible keys for object storage
• Add an SSH key pair to your account: generate and upload an ed25519 key
• Install the OpenStack client: set up the openstack command
• Service endpoints: base URLs and clouds.yaml discovery
• Account model: how projects scope the credentials above