Connect with kubectl

Once your cluster’s status is running, you connect to it with kubectl using the admin kubeconfig you download from the portal.

The API server endpoint

Every cluster is reachable at a stable public domain, assigned when the cluster is created:

<cluster>.<org>.<region>.aetherplatform.cloud:6443

That’s the address your kubeconfig points at, so kubectl works from your laptop or a CI pipeline with no VPN or bastion host. Your worker nodes keep talking to the API server over the cluster’s private network.

The endpoint is mandatory: every cluster has one, and it is billed at €4 per month (see the Billing model). Private-network-only connectivity to the API server, which would make the public endpoint optional, is a future capability and is not available today.

Authorized networks

Two controls guard the API endpoint, both configured per cluster:

• Authorized networks — the source CIDRs allowed to reach the API server.
• Connection rate limiting — a cap on new connections per second.

Lock down the allow-list

The authorized-networks list starts empty, and empty means the API endpoint accepts connections from any source address. Authentication still applies — nobody gets in without a valid credential (a client certificate or a ServiceAccount token), and Kubernetes RBAC governs what those credentials can do (the admin kubeconfig is the exception: its system:masters certificate sits above RBAC, see below) — but the port is open to the internet until you populate the list. Set it to the ranges you actually connect from: your office, your VPN, and your CI provider’s egress ranges.

Setting one or more CIDRs restricts the endpoint at both the cluster firewall and the API front-end. The cluster’s own workers and the platform are always allowed in addition to your list.

Set it in the portal (your cluster → API server access → Edit, one CIDR per line) or over the REST API, with a PUT to the cluster’s /network resource — see the API reference. Both write the same list.

Connect

1. In the portal, open your cluster and click Download kubeconfig.

2. Point kubectl at the downloaded file:

   export KUBECONFIG=/path/to/downloaded-kubeconfig.yaml

3. Verify the connection:

   kubectl get nodes

   You should see the worker nodes from your pools listed in Ready state. If you haven’t created a node pool yet, the list is empty — the control plane is up, but nothing is running workloads. See Node pools.

Not available yet?

The kubeconfig is only served once the cluster’s status is running and its control plane has finished coming up. Until then the download returns a “not ready” error — wait for the cluster to settle and try again.

Fetching it from the API instead

For CI, fetch the same kubeconfig over the HTTP API with an API token rather than downloading it by hand.

The host below is the production API, api.aetherplatform.cloud.

curl -fsSL \
  -H "Authorization: Bearer $AETHER_API_TOKEN" \
  https://api.aetherplatform.cloud/api/v1/organizations/$ORG_ID/clusters/$CLUSTER_ID/kubeconfig \
  -o kubeconfig.yaml

It returns the kubeconfig as application/yaml. See the API reference.

Merging into your existing kubeconfig

To keep multiple clusters in one file, merge the downloaded kubeconfig into ~/.kube/config:

cp ~/.kube/config ~/.kube/config.bak-$(date +%Y%m%d-%H%M%S) \
  && NEW=$(mktemp ~/.kube/config.XXXXXX) \
  && KUBECONFIG=~/.kube/config:/path/to/downloaded-kubeconfig.yaml \
       kubectl config view --flatten --raw > "$NEW" \
  && mv "$NEW" ~/.kube/config

--raw is required because kubectl config view redacts certificate and key data without it, so a merge without it writes a kubeconfig that cannot authenticate. The copy is your rollback, and the chain stops if it cannot be made. mktemp creates a fresh file readable only by you before anything is written into it, and it replaces your kubeconfig only if the merge succeeded.

Then list the contexts with kubectl config get-contexts and switch with kubectl config use-context <name>.

Credential lifetime, rotation and offboarding

Read this before you share a kubeconfig with anyone.

The kubeconfig you download carries an x509 client certificate for kubernetes-admin in the system:masters group — full administrative rights on the cluster, above every RBAC rule you write. It is valid for one year from the cluster’s creation, and it is a standalone credential: it is not tied to a portal session, it does not stop working when someone leaves your organization, and removing a member from the portal does not revoke a kubeconfig they have already downloaded.

• There is no self-service rotation or revocation today. Kubernetes has no certificate revocation, so an issued admin certificate cannot be withdrawn.
• If a kubeconfig may have been exposed, the supported responses are to delete and recreate the cluster, or to open a support request.
• Don’t hand the admin kubeconfig around. Mint RBAC-scoped ServiceAccount tokens inside the cluster instead, one per person or per pipeline. Those you can revoke yourself, without touching the cluster’s admin credential.
• A downloaded copy is detached from the cluster: if the cluster’s endpoint changes, download the kubeconfig again rather than editing the old file.

The one-year expiry has no renewal path today

The admin certificate expires one year after the cluster was created, and Aether has no renewal or rotation feature yet. Plan for that on long-lived clusters, and open a support request before you get there.

Next steps

• Networking — expose your workloads.
• Storage — add persistent volumes.