SecureAnyCloud
Deployment guide

Rancher

Overview

Rancher is a Kubernetes management platform. It gives you a single control plane for provisioning, importing, observing and governing Kubernetes clusters wherever they run, with a full web dashboard, centralized authentication and RBAC, a built-in Helm chart catalog, and cluster-wide monitoring, logging and policy.

The SecureAnyCloud image ships Rancher 2.14.3, the free and open source Apache-2.0 release. It is installed the way upstream supports for real workloads: the official rancher-stable Helm chart on a single-node K3s cluster running on the VM itself, with cert-manager issuing the TLS certificate. Upstream's Docker-based install is explicitly not supported in production, so this image does not use it.

Rancher is a trademark of its respective owner. This image is produced by SecureAnyCloud and is not affiliated with, endorsed by, or sponsored by SUSE or the Rancher project. It ships the free and open source Apache-2.0 software, unmodified.

What you get:

  • Rancher 2.14.3 (the Apache-2.0 release), installed from the official rancher-stable Helm chart.
  • K3s v1.35.5+k3s1 as the underlying single-node Kubernetes cluster, with embedded etcd, containerd, CoreDNS, Traefik and ServiceLB.
  • cert-manager v1.19.2, which issues the Rancher TLS certificate.
  • All Rancher, cert-manager and K3s container images pre-staged into the image, so the cluster comes up on first boot without reaching out to a registry.
  • A dedicated 64 GiB data volume mounted at /var/lib/rancher for cluster state and the container image store.
  • k3s.service and rancher-firstboot.service as systemd units, enabled and active on boot.
  • A unique 24-character administrator password generated per VM on first boot, before the port is reachable, and never baked into the image. Nothing ships with a known secret.
  • A clean cluster on first boot. The build-time cluster, its certificate authority and its join tokens are destroyed before the image is captured.
  • 24/7 SecureAnyCloud support.

Prerequisites

You need:

  • An active Azure subscription.
  • An SSH key pair.
  • A VNet and subnet in the target region.
  • A VM size of Standard_B4ms (4 vCPU / 16 GiB RAM). Rancher's own sizing guidance is the floor here, because the VM runs both the Kubernetes control plane and the Rancher management server.
  • NSG inbound rules that allow 22/tcp from your management network and 443/tcp for the dashboard and API. Port 80/tcp is served too and redirects to 443.
  • If you plan to import or provision downstream clusters, a network path that lets those clusters reach this VM on 443/tcp.

This is a single-node, non-highly-available Rancher server. It is well suited to evaluation, development and managing a modest number of downstream clusters. For a production control plane that must survive the loss of a node, upstream recommends running Rancher on a three-node cluster.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal and choose Create a resource. Search the Marketplace for Rancher by SecureAnyCloud, and select Create.

On Basics, pick your subscription, resource group, region and size. Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22) and HTTPS (443). Then choose Review + create, then Create.

Step 2 - Deploy from the Azure CLI

Accept the Marketplace terms once per subscription, then create the VM.

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:rancher-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name rancher \
  --image sac1647283583153:rancher-ubuntu-24-04:default:latest \
  --size Standard_B4ms \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard
az vm open-port --resource-group <your-rg> --name rancher --port 443 --priority 1010

Step 3 - Connect to your VM

Connect over SSH as azureuser.

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the cluster and Rancher are running

On first boot, the image generates a unique administrator password, starts K3s, restores the pre-staged container images, and rolls out Rancher and cert-manager. On a Standard_B4ms, this takes a couple of minutes. Confirm that K3s is active, the node is Ready, and the Rancher deployment is available.

systemctl is-active k3s
sudo k3s kubectl get nodes
sudo k3s kubectl -n cattle-system get deploy rancher

k3s reports active, the node reports Ready with role control-plane, and the rancher deployment reports 1/1 ready.

Rancher answers on 443, and 80 redirects to it. The liveness endpoint needs no credentials. Check the endpoints.

curl -sk -o /dev/null -w 'healthz: HTTP %{http_code}\n' https://127.0.0.1/healthz
curl -sk -o /dev/null -w 'dashboard: HTTP %{http_code}\n' https://127.0.0.1/dashboard/
curl -s -o /dev/null -w 'port 80: HTTP %{http_code}\n' http://127.0.0.1/

Both HTTPS endpoints return 200 and port 80 returns 302, the redirect to HTTPS.

Rancher serves traffic through the Kubernetes ingress, which K3s publishes with ServiceLB using iptables DNAT instead of a process listening on the host. As a result, ss -ltn does not show ports 80 and 443, even though both are served correctly. Check them with curl, not with the listener table.

Step 5 - Secure by default: no login ships with the image

Rancher holds the keys to every cluster you attach to it, so it must never ship with a known password. The administrator password is generated uniquely for this VM on first boot. The build-time cluster, including its certificate authority and join tokens, is destroyed before the image is captured. Confirm that an unauthenticated caller cannot read the cluster inventory.

curl -sk -o /dev/null -w 'no credentials: HTTP %{http_code}\n' https://127.0.0.1/v3/clusters

It returns HTTP 401. Known default passwords are rejected, only this VM's generated password is accepted, and the underlying Kubernetes API refuses anonymous callers as well.

Your password is written to /root/rancher-credentials.txt, readable only by root. Check the file's permissions.

sudo stat -c '%a %U:%G' /root/rancher-credentials.txt

It reports 600 root:root. View the access notes, which hold the URL, the administrator login and password, and the API details.

sudo cat /root/rancher-credentials.txt

Step 6 - Sign in to the dashboard

Browse to https://<vm-public-ip>/. The VM uses a certificate that cert-manager issued for it, so your browser warns on the first visit. Accept the warning, and replace the certificate with your own (see Step 10). Rancher asks for the administrator password from your access notes.

Username: admin Password: <the rancher.admin.pass value from /root/rancher-credentials.txt>

On first sign-in, Rancher asks for the server URL it should advertise to the clusters it manages, and asks you to accept the End User License Agreement. Set the URL to the address your downstream clusters will use to reach this VM. This is normally https://<vm-public-ip> or your own DNS name.

Rancher then opens on its home page, which lists the clusters it manages. The local cluster is the K3s cluster running on this VM. It is shown as Active, with its Kubernetes version, node count and capacity.

Step 7 - Explore the cluster

Select the local cluster to open Cluster Explorer, Rancher's view of a single cluster. It shows total resources, node and deployment counts, live pod, CPU and memory capacity, the health of etcd, the scheduler and the controller manager, and the cluster's event stream.

The Nodes view lists the machines in the cluster with their roles, Kubernetes version and live CPU and memory usage. This image has a single node, which carries the control plane role and runs your workloads.

Under Apps, Rancher ships a Helm chart catalog wired to the Rancher, Partners and RKE2 repositories. You can install monitoring, logging, service mesh, backup and third-party applications into the cluster without leaving the dashboard.

Step 8 - Drive the cluster through Rancher's API

Everything the dashboard does is available over Rancher's REST API, and Rancher proxies the Kubernetes API of every cluster it manages. Authenticate with the per-VM password to get a bearer token, then read the cluster back.

PASS=$(sudo grep '^RANCHER_BOOTSTRAP_PASSWORD=' /root/rancher-credentials.txt | cut -d= -f2-)
TOKEN=$(curl -sk -X POST 'https://127.0.0.1/v3-public/localProviders/local?action=login' \
  -H 'Content-Type: application/json' \
  -d "{\"username\":\"admin\",\"password\":\"$PASS\"}" \
  | python3 -c 'import sys,json;print(json.load(sys.stdin)["token"])')
curl -sk -H "Authorization: Bearer $TOKEN" https://127.0.0.1/v3/clusters/local \
  | python3 -c 'import sys,json;d=json.load(sys.stdin);print("cluster:",d["id"],"state:",d["state"],"k8s:",d["version"]["gitVersion"],"nodes:",d["nodeCount"])'

The login returns HTTP 201 with a bearer token, and the cluster reports state: active with its Kubernetes version and node count.

Rancher's cluster proxy at /k8s/clusters/<cluster-id> speaks the Kubernetes API for any cluster under management, so the same token drives real changes. Create a namespace through Rancher, confirm that it landed in the cluster, then remove it.

PASS=$(sudo grep '^RANCHER_BOOTSTRAP_PASSWORD=' /root/rancher-credentials.txt | cut -d= -f2-)
TOKEN=$(curl -sk -X POST 'https://127.0.0.1/v3-public/localProviders/local?action=login' \
  -H 'Content-Type: application/json' \
  -d "{\"username\":\"admin\",\"password\":\"$PASS\"}" \
  | python3 -c 'import sys,json;print(json.load(sys.stdin)["token"])') PROXY=https://127.0.0.1/k8s/clusters/local curl -sk -o /dev/null -w 'create: HTTP %{http_code}\n' -X POST "$PROXY/api/v1/namespaces" \
  -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"apiVersion":"v1","kind":"Namespace","metadata":{"name":"sac-demo"}}'
sudo k3s kubectl get namespace sac-demo curl -sk -o /dev/null -w 'delete: HTTP %{http_code}\n' -X DELETE \
  "$PROXY/api/v1/namespaces/sac-demo" -H "Authorization: Bearer $TOKEN"

The create returns HTTP 201, kubectl shows the namespace Active, and the delete returns HTTP 200.

For your own tooling, generate a long-lived API key from the dashboard under the user menu, Account & API Keys, instead of reusing the sign-in token. Run this command from your own machine.

curl https://<vm-public-ip>/v3/clusters \
  -H 'Authorization: Bearer <your-api-key>'

Step 9 - Add your existing clusters

The point of Rancher is managing clusters beyond this VM. From the home page, choose Import Existing and name the cluster. Rancher gives you a single kubectl apply command to run against that cluster.

The cluster's agent connects outbound to the server URL you set in Step 6. The downstream cluster does not need to be reachable from this VM, but it does need to reach this VM on 443/tcp. Once connected, it appears alongside local with the same dashboard, catalog, RBAC and policy tooling.

Choose Create instead to provision new clusters into a cloud provider or onto existing machines, using the node drivers Rancher ships.

Step 10 - Production: your own domain and certificate

For production, put Rancher on your own DNS name with a certificate that your browsers and cluster agents already trust. Point a DNS record at the VM public IP. Then, in the dashboard under Global Settings, set server-url to that name.

To replace the certificate, supply your own through cert-manager, or install it as the tls-rancher-ingress secret in the cattle-system namespace. Follow upstream's TLS documentation for the release you are running.

Because Rancher governs every cluster you attach, treat this VM as tier-zero infrastructure.

  • Restrict inbound access in your NSG to 443/tcp from the networks that need it, and to 22/tcp from your management network only.
  • Keep /root/rancher-credentials.txt confidential.
  • Replace the initial administrator password with your own, and add named user accounts.
  • Back up /var/lib/rancher, which holds the cluster's etcd datastore and its certificate authority.

Support

SecureAnyCloud supports this image 24/7. For help with deployment or configuration, contact support through secureanycloud.com.

Deploy on Azure

Launch Rancher on Ubuntu 24.04 LTS on Azure, with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on Azure