# Credentials and tools

Source: https://docs.quake.ai/docs/tools/concepts
Markdown: https://docs.quake.ai/docs/tools/concepts.md
> How the OpenStack CLI, application credentials, API tokens, S3 credentials, and SSH keys relate: what each authentication surface is, what it reaches, how scoping works, and which tool consumes it.

---

# 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.

<Figure caption="Each tool consumes one credential type, and each credential type reaches a specific scope">

```d2
tools: Your tools {
  cli: OpenStack CLI, SDKs, Terraform
  http: curl / HTTP client
  s3tools: AWS CLI, rclone, boto3
  ssh: SSH client
}

credentials: Credentials {
  appcred: Application credentials
  token: API token
  s3cred: S3 credentials
  sshkey: SSH key pair
}

scopes: What they reach {
  project: Project API
  objstore: Object storage
  instance: Instance login
}

tools.cli -> credentials.appcred -> scopes.project
tools.http -> credentials.token -> scopes.project
tools.s3tools -> credentials.s3cred -> scopes.objstore
tools.ssh -> credentials.sshkey -> scopes.instance
```

</Figure>

**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](/docs/tools/app-credentials) and [Generate application credentials](/docs/tools/generate-app-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](/docs/tools/api-tokens).

**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](/docs/tools/s3-credentials) and [How to create S3 credentials](/docs/object/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](/docs/tools/add-ssh-key).

## How credential scope works

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

| Credential | Issued by | Scope | Lifetime | Tools |
|---|---|---|---|---|
| Application credentials | Identity (Keystone) | One project | Until deleted or expired | OpenStack CLI, SDKs, Terraform, Ansible |
| API token | Identity (Keystone) | One project | 24 hours | `curl` and other HTTP clients |
| S3 credentials | Object storage (EC2-compatible) | Your user, object storage across all projects | Until deleted | AWS CLI, `s3cmd`, `rclone`, `boto3` |
| SSH key pair | Your account | Your user, instance login across all projects | Until removed | SSH client |

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](/docs/account/concepts). 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](/docs/tools/install-openstack-client) and the [OpenStack client guide](/docs/tools/openstack-cli) to set this up, and [CLI debugging](/docs/tools/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](/docs/tools/app-credentials): fields, actions, and access rules
- [Generate application credentials](/docs/tools/generate-app-credentials): create credentials and configure `clouds.yaml`
- [How to get an API token](/docs/tools/api-tokens): project-scoped tokens for HTTP requests
- [S3 credentials reference](/docs/tools/s3-credentials): EC2-compatible keys for object storage
- [Add an SSH key pair to your account](/docs/tools/add-ssh-key): generate and upload an `ed25519` key
- [Install the OpenStack client](/docs/tools/install-openstack-client): set up the `openstack` command
- [Service endpoints](/docs/tools/service-endpoints): base URLs and `clouds.yaml` discovery
- [Account model](/docs/account/concepts): how projects scope the credentials above