Skip to main content

Cloud Credentials

Cloud Credentials authorize Anycloud to provision resources in your AWS, Azure, GCP, or Lambda account. Save multiple named credentials when you want to use several accounts or let Anycloud choose across them.

Cloud credentials are distinct from Secrets: credentials let Anycloud manage infrastructure; secrets become environment variables inside your workload.

Create credentials​

The interactive wizard can import local AWS or GCP credential material, create an Azure service principal with the Azure CLI, or accept existing values:

anycloud credentials new production-aws

For automation, supply the provider fields:

# AWS
anycloud credentials new production-aws --provider aws \
  --access-key-id AKIA... \
  --secret-access-key ...

# Import a durable static AWS profile
anycloud credentials new production-aws --provider aws \
  --profile production

# Azure
anycloud credentials new production-azure --provider azure \
  --application-id ... \
  --secret ... \
  --subscription-id ... \
  --directory-id ...

# Explicitly create an Azure service principal with the logged-in Azure CLI
anycloud credentials new production-azure --provider azure --generate

# GCP
anycloud credentials new production-gcp --provider gcp \
  --project-id my-project \
  --client-email service-account@my-project.iam.gserviceaccount.com \
  --private-key "..."

# Lambda
anycloud credentials new production-lambda --provider lambda \
  --api-key ...

Provider secret flags also accept their documented environment-variable fallbacks. An explicit flag wins.

Import and Azure generation​

Ordinary AWS onboarding imports only durable access-key profiles. If one static profile exists, the wizard imports it; if several exist, it asks which one to use. It can also import one directly with --profile. Anycloud authenticates the exact imported, pasted, or environment-provided keys with STS before saving, but does not treat identity authentication as proof of every EC2, S3, IAM, quota, or organization-policy permission.

SSO, role, web-identity, credential-process, and session-token profiles are not durable and cannot be imported. Anycloud does not configure SSO, use a dynamic profile to create an IAM user, or accept --generate for AWS. Create durable access keys outside Anycloud, then import their static profile or enter them.

GCP onboarding similarly imports a service-account key JSON file discovered through GOOGLE_APPLICATION_CREDENTIALS, the conventional ADC path, or ~/.anycloud; it can also accept the three service-account fields directly. User ADC is not durable service-account material. Anycloud does not use it to create a service account, and --generate is unsupported for GCP.

Azure CLI user sessions cannot reveal an existing service principal secret, so Azure retains an explicit creation path. The wizard separates Enter existing service principal credentials from Create a service principal with Azure CLI. Before creation it displays the tenant, subscription, scope, Contributor role, and User Access Administrator role and requires confirmation.

Generated credentials and first-use recovery​

Azure generation keeps exactly two subscription-scoped controller assignments: Contributor and User Access Administrator. It saves the generated credential after the owned application, service principal, client secret, and assignments are created; saving does not perform a separate ARM readiness probe. Controller Blob operations use a current account key fetched through listKeys; the controller does not receive a subscription-wide Blob data role.

Azure authorization can still be propagating when the credential is first used. At the compute validation, storage, and controller-managed role-assignment operations that observe the failure, the API retries only Azure's specific ARM AuthorizationFailed and Entra AADSTS7000215 shapes. Recovery is capped at nine attempts over 39.5 seconds and refreshes authentication between attempts. It does not depend on credential age, a readiness probe, or a previous success.

An unrelated 403, an expired secret (AADSTS7000222), or a generic invalid_client failure receives no special propagation retry. A persistently broken secret therefore exhausts at most the bounded recovery window and then fails normally. Generation or persistence failures retain ownership-checked rollback. Imported and manually entered AWS keys use the narrower exact-key STS authentication described above. Removing AWS and GCP generation does not delete credentials or provider resources created by an older release.

anycloud credentials list
anycloud credentials edit production-aws
anycloud credentials delete production-aws

See credentials reference for every field and wizard mode.

Select credentials for compute​

Select a named credential when account choice is part of the workload:

anycloud job ghcr.io/acme/train:latest \
  --credentials production-aws \
  --gpu-type h100

In Python, pass the name in the generated admission model:

from anycloud.models.deployment_admission_input import DeploymentAdmissionInput

request = DeploymentAdmissionInput.from_dict({
    "image": "ghcr.io/acme/train:latest",
    "credentialName": "production-aws",
    "gpuType": "h100",
    "cloudConfig": {},
})

If --credentials and ANYCLOUD_CREDENTIALS_NAME are absent, the CLI selects the sole saved credential automatically. With several saved credentials, an interactive terminal shows a picker; non-interactive use must pass --credentials. Generated clients send the named or inline credential in the request and do not perform credential discovery.

Each remote deployment uses one compute credential for its lifetime. If the cloud rejects that credential, the deployment becomes invalid; Anycloud does not switch accounts. Region can remain unset so the deployment can still fail over between regions in the selected account. Local compute does not require a cloud credential. Workers select a Ready cluster when they are created; targeted Jobs use the Worker's shared capacity and cannot select infrastructure credentials.

Storage credentials​

Same-cloud Bucket access uses the workload VM's cloud-native identity. When a Bucket belongs to a different account, give it a separate storage credential:

anycloud job ghcr.io/acme/train:latest \
  --credentials compute-account \
  --input-bucket training-data \
  --input-storage-credentials storage-account \
  --input-storage-region us-east-1

Input, output, and checkpoint storage identities are independent. See Buckets.

Local security model​

Saved cloud credentials live in the local Anycloud API database at ~/.anycloud/api.db. They are encrypted at rest with libsodium (XSalsa20-Poly1305) using a locally generated key at ~/.anycloud/cipher.key. Anycloud communicates directly with the cloud provider rather than sending the credentials to an Anycloud-hosted service.

The database records the identity of the API that owns it, and cloud resources carry that identity in their tags. To move a local API installation, copy the whole ~/.anycloud state, including cipher.key; the database keeps its identity, so the resources it created stay recognisably its own.

Each deployment receives a unique ED25519 SSH keypair. The private key remains encrypted in the local API database; commands such as anycloud exec ask the API to perform the SSH operation rather than returning the key to the CLI.

Same-cloud storage uses VM identities instead of putting long-lived provider keys inside the container. Cross-cloud S3 sync uses a scoped, expiring STS token.