> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ankra.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Ankra Cloud Credentials

> Store an Ankra Cloud API token in Ankra to build self-managed kubeadm or k3s clusters on Ankra Cloud servers and to provision Ankra Cloud Kubernetes.

An Ankra Cloud credential stores an Ankra Cloud API token. One credential serves both cluster types on [Ankra Cloud](https://cloud.ankra.app): self-managed [Ankra Cloud clusters](/guides/ankra-cloud-clusters) and managed [Ankra Cloud Kubernetes](/guides/ankra-cloud-kubernetes).

<Warning>
  **Closed beta.** Ankra Cloud as a cluster provider is in closed beta. The workflow is stable but the surface may still change, and it is enabled per organisation on request - until it is, Ankra Cloud is not offered as a credential provider. [Contact support](/platform/support) to have it turned on for your organisation.
</Warning>

The token is validated when you save it: Ankra lists the zones and plans of the account (`GET /v1/zones` and `GET /v1/plans`), so a rejected or mistyped token is refused immediately. The token never appears in an error message or on the credential's page.

## What Ankra Accesses

For self-managed clusters, Ankra provisions the infrastructure directly:

| Resource | Operations | Why it's used |
| - | - | - |
| Zones, plans, templates, storage tiers | read | The wizard's live catalog and pricing |
| Servers | create, read, start/stop/restart, delete | The cluster's nodes and bastion |
| Server firewalls | update | Per-server inbound rules |
| Private networks | create, read, delete | The cluster's private network |
| Routers | create, read, delete | NAT egress for the nodes |
| Load balancers, storages | read, delete | Created by the in-cluster CCM and CSI driver - Ankra only cleans them up when you delete the cluster |

For [Ankra Cloud Kubernetes](/guides/ankra-cloud-kubernetes), Ankra uses the managed Kubernetes API instead:

| Resource | Operations | Why it's used |
| - | - | - |
| Kubernetes clusters | create, read, upgrade, delete | Cluster lifecycle |
| Node pools | create, read, update, delete | Scale and manage the cluster's node pools |
| Kubeconfig | read | Install Ankra's agent; fetched fresh each time and never stored |
| Private networks | create, read, delete | The network the cluster's nodes join |
| Versions, plans, zones | read | Available Kubernetes versions, plans, zones and the control-plane fee |

## Creating an Ankra Cloud credential

<Steps>
  <Step title="Create an Ankra Cloud API token">
    1. Sign in to the [Ankra Cloud console](https://cloud.ankra.app)
    2. Open **Settings** → **API tokens** (owners and admins)
    3. Create a token and copy it (prefixed with `act_`; shown once)

    The token acts with the current role of the user who created it. That user must be allowed to operate the account - create servers, networks, routers and Kubernetes clusters. A read-only user's token passes the save-time check but fails when Ankra provisions.
  </Step>

  <Step title="Add to Ankra">
    Go to **Credentials** → **Add** → **Ankra Cloud**, then provide:

    * **Name**: a unique identifier (e.g. `ankra-cloud-prod`)
    * **API Token**: the `act_...` token from the previous step
    * **API endpoint** (optional): only for a private or development Ankra Cloud. It must be an `https://` URL; leave it empty to use `https://cloud.ankra.app`

    Click **Test connection** to verify the token, then save. You can also add the credential inline from either create-cluster wizard.
  </Step>
</Steps>

For self-managed clusters you also need an [SSH key credential](/platform/credentials/ssh-key). Ankra Cloud Kubernetes needs none.

<Note>
  The token can be rotated later from the credential's **Rotation** tab without recreating the credential - everything using it picks up the new token automatically.
</Note>

## Runtime credential

A self-managed cluster runs the Ankra Cloud cloud controller manager and CSI driver inside the cluster, and they need a token too. The create wizard's **Runtime credential** picks which Ankra Cloud credential they get: by default the provisioning credential, or a second, dedicated one. A dedicated runtime credential limits what a compromised workload in the cluster could reach through that token. Ankra stores it in the Secret `ankra-cloud` in `kube-system`, SOPS-encrypted when the stack is committed to Git.

## Listing Ankra Cloud credentials

```bash theme={null}
curl https://platform.ankra.app/api/v1/credentials/ankracloud \
  -H "Authorization: Bearer $ANKRA_API_TOKEN"
```

## Troubleshooting

| Symptom | Cause | Solution |
| - | - | - |
| The credential is refused on save | The token is invalid, revoked, or copied incompletely | Create a new token and paste the full `act_...` value |
| The endpoint is refused | The endpoint is not an `https://` URL | Use `https://`, or leave it empty for `https://cloud.ankra.app` |
| The credential saves, but provisioning fails with a permissions error | The token's user may not operate the account | Give that user an operating role, or create a token as a user who has one and rotate it in |
| Provisioning fails with a payment or suspension error | The Ankra Cloud account needs a payment method or is suspended | Resolve it in the Ankra Cloud console, then retry |