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: self-managed Ankra Cloud clusters and managed Ankra Cloud Kubernetes.

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 to have it turned on for your organisation.

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
Storages	read, delete	Persistent volumes the in-cluster CSI driver creates. When you delete the cluster, Ankra deletes them or keeps them, following the cluster’s storage retention policy
Load balancers	none	Created and removed by the in-cluster cloud controller with the runtime credential, as LoadBalancer Services come and go. Ankra itself never lists or deletes them

Because Ankra does not clean up load balancers, delete a cluster’s LoadBalancer Services before you delete the cluster. A load balancer the cloud controller has not removed by then stays in your Ankra Cloud account, and is billed, until you delete it in the Ankra Cloud console.

For 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 and zones, and the production and development control planes with their fees

Creating an Ankra Cloud credential

1. Create an Ankra Cloud API token

   1. Sign in to the Ankra Cloud console
   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.

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

For self-managed clusters you also need an SSH key credential. Ankra Cloud Kubernetes needs none.

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.

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

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