SecureAnyCloud
Deployment guide

MicroCeph

Overview

MicroCeph is Canonical's distribution of Ceph, built for single-node and edge deployments. It packages the full Ceph storage engine as a single snap, so you get object, block and file storage on a self-healing, strongly consistent cluster that stands up on one machine.

This SecureAnyCloud image ships MicroCeph 19.2.3 (Ceph "Squid") and turns a single Azure VM into a working, S3-compatible object store within minutes of launch. At first boot, the appliance bootstraps its own single-node cluster and provisions loop-file-backed OSDs, so it runs standalone with no extra block devices. It enables the RADOS Gateway (RGW) as a TLS S3 endpoint and reaches Ceph HEALTH_OK out of the box. Point any S3 client, SDK or backup tool at it and start creating buckets and objects.

What you get:

  • MicroCeph 19.2.3 (Ceph "Squid") from the squid/stable snap track, held so that an unattended refresh can never move your storage cluster to a new Ceph major version
  • A single-node cluster (mon, mgr, 3 OSDs) bootstrapped fresh on each VM, reaching HEALTH_OK
  • The RADOS Gateway S3 object endpoint on TLS port 443, with per-VM keys and a per-VM certificate
  • microceph-firstboot.service, which bootstraps the cluster, provisions OSDs, enables RGW and mints per-VM credentials
  • An Ubuntu 24.04 LTS base, patched at build time, with unattended security upgrades enabled
  • Licences shipped at /usr/share/doc/sac/ (MicroCeph AGPL-3.0; Ceph LGPL-2.1)
  • 24/7 SecureAnyCloud support, with a 24-hour response SLA

Security by design

The appliance exposes only two surfaces: SSH and the S3 endpoint (TLS 443). There is no web console, no management port and no cleartext object port.

  • The cluster is bootstrapped per VM, never at build time. microceph cluster bootstrap binds the Ceph monitor to the VM's own address and generates the cluster's auth keyrings. Doing that during the build would bake a shared cluster key and the build VM's IP into every image. Instead, the shipped image carries only the installed snap. Each VM bootstraps its own cluster and mints its own secrets on first boot.
  • No baked S3 keypair. On first boot, every instance generates a fresh S3 access key and secret key and creates the RGW admin user. It writes them to a root-only file, together with the cluster FSID and the S3 endpoint URL resolved to this VM's own public IP. No two machines share a secret, and there is no default to guess.
  • TLS only. The S3 endpoint is served over HTTPS on port 443 using a per-VM self-signed certificate generated at first boot. When a certificate is supplied, MicroCeph binds RGW on 443 only. There is no cleartext listener.
  • Administration over your own key-based SSH. There is no product login to harden.

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet.

Standard_B2s (2 vCPU, 4 GB RAM) is the recommended size. Bootstrap, three loop OSDs, the S3 gateway and a full round trip all run within it.

For larger object capacity, grow the OSD size or count, or attach a dedicated Azure data disk (see Scaling capacity).

1

Deploy the virtual machine

Option A: Azure Portal

Search the Marketplace for MicroCeph Single-Node Object Storage on Ubuntu 24.04, choose your VM size and provide your SSH public key. Attach a network security group that allows:

  • TCP 22 (admin SSH) from your management network only.
  • TCP 443 (the S3 endpoint) from the clients that will use the object store.

Option B: Azure CLI

Run the commands below to create the resource group, network, security rules and VM. Replace <your-mgmt-cidr> and <your-client-cidrs> with your own address ranges.

RG="microceph-prod"; LOCATION="eastus"; VM_NAME="microceph-01" IMAGE_URN="sac1647283583153:microceph:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION" az network vnet create -g "$RG" --name microceph-vnet --address-prefix 10.80.0.0/16 --subnet-name microceph-subnet --subnet-prefix 10.80.1.0/24 az network nsg create -g "$RG" --name microceph-nsg az network nsg rule create -g "$RG" --nsg-name microceph-nsg --name allow-admin-ssh --priority 100 \
  --source-address-prefixes "<your-mgmt-cidr>" --destination-port-ranges 22 --access Allow --protocol Tcp az network nsg rule create -g "$RG" --nsg-name microceph-nsg --name allow-s3 --priority 110 \
  --source-address-prefixes "<your-client-cidrs>" --destination-port-ranges 443 --access Allow --protocol Tcp
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:microceph:default:latest
az vm create -g "$RG" --name "$VM_NAME" --image "$IMAGE_URN" --size Standard_B2s \
  --admin-username azureuser --ssh-key-values "$SSH_KEY" \
  --vnet-name microceph-vnet --subnet microceph-subnet --nsg microceph-nsg --public-ip-sku Standard
2

Connect via SSH

ssh azureuser@<public-ip>

First boot bootstraps the cluster and mints your keys. It typically completes within two to three minutes of the VM starting. Watch its progress with journalctl -u microceph-firstboot.service -f.

3

Confirm the cluster is healthy

Check the cluster status and health:

sudo microceph.ceph -s sudo microceph.ceph health

microceph.ceph -s shows the cluster identity, health: HEALTH_OK, one mon and one mgr, three OSDs up and in, and the RGW daemon active.

4

The S3 gateway

The RADOS Gateway serves the S3 API over TLS on port 443. Confirm that it is active, listening and answering:

sudo systemctl is-active snap.microceph.rgw.service
sudo ss -ltnp | grep radosgw curl -sk https://127.0.0.1/ -o /dev/null -w 'RGW HTTPS status: %{http_code}\n'

The gateway listens on :443 only, and there is no cleartext port. The certificate is a per-VM self-signed certificate whose subject alternative names include this VM's public and private IPs.

Trust the certificate in your client's CA store. For development, you can instead pass the client's --no-verify-ssl flag or its equivalent.

5

Retrieve your per-VM S3 credentials

Every instance writes its own S3 credentials to a root-only file at first boot. Read the file as root:

sudo cat /root/microceph-credentials.txt

The file contains S3_ENDPOINT_URL (this VM's public IP, over HTTPS), S3_ACCESS_KEY, S3_SECRET_KEY, the RGW user (SecureAnyCloud) and the cluster CEPH_FSID. These values are unique to this VM, and nothing is baked into the image.

6

Your first S3 round-trip

A bundled helper proves that the object store works end to end. It reads the per-VM keys, creates a bucket, writes an object, reads it back and verifies the bytes:

sudo /usr/local/sbin/microceph-s3-roundtrip.py

The helper prints S3_ROUNDTRIP_OK. SecureAnyCloud runs the same check at build time and again on a fresh VM, so it confirms the object store works, not merely that the port is open.

7

Use it from your own machine

The endpoint speaks the S3 API, so any S3 client works. The example below uses the AWS CLI with the keys from /root/microceph-credentials.txt and the VM's public IP. The certificate is self-signed, so the example passes --no-verify-ssl for development.

$ export AWS_ACCESS_KEY_ID=<s3-access-key> $ export AWS_SECRET_ACCESS_KEY=<s3-secret-key> $ aws --endpoint-url https://<public-ip> --no-verify-ssl s3 mb s3://my-bucket $ aws --endpoint-url https://<public-ip> --no-verify-ssl s3 cp ./report.pdf s3://my-bucket/ $ aws --endpoint-url https://<public-ip> --no-verify-ssl s3 ls s3://my-bucket

For production, add the per-VM certificate (/etc/sac/tls/rgw.crt) to your client's trust store instead of disabling verification. Alternatively, place the endpoint behind your own DNS name and certificate.

Scaling capacity

The default cluster uses three 4 GiB loop-file OSDs on the OS disk, which is ample for development and testing. To grow capacity, choose one of these options:

  • Add more loop OSDs. sudo microceph disk add loop,10G,3 adds three 10 GiB OSDs. Make sure the OS disk has room, or attach a larger OS disk.
  • Use a real Azure data disk (recommended for production). Attach an empty data disk to the VM, then add it as an OSD with sudo microceph disk add /dev/disk/azure/scsi1/lun0. Ceph then stores data on dedicated block storage rather than loop files.

Check capacity at any time with sudo microceph.ceph df.

Managing the service

Use these commands to check cluster status, restart the S3 gateway and inspect the RGW user:

sudo microceph.ceph -s
# cluster status and health
sudo microceph status
# microceph node/service view
sudo systemctl restart snap.microceph.rgw.service
# restart the S3 gateway
sudo microceph.radosgw-admin user info --uid=sac
# inspect the RGW user

To create additional, scoped S3 users, run sudo microceph.radosgw-admin user create --uid=<name> --display-name=<name>. The command returns a fresh access and secret keypair for that user.

Server components

  • MicroCeph 19.2.3: Ceph "Squid" packaged as a single snap (squid/stable, held)
  • Ceph mon + mgr: the single monitor and manager for the cluster
  • 3 OSDs: loop-file-backed object storage daemons that provide a 3-replica cluster on one host
  • RADOS Gateway (radosgw): the S3-compatible object endpoint on TLS 443
  • microceph-firstboot.service: per-VM bootstrap, OSD provisioning, RGW enablement and key minting

Filesystem layout

  • /root/microceph-credentials.txt: per-VM S3 keys, endpoint URL, RGW user and FSID (0600 root:root)
  • /etc/sac/tls/rgw.crt, rgw.key: per-VM RGW TLS certificate and key
  • /var/snap/microceph/common/: MicroCeph state, OSD loop files and data
  • /usr/local/sbin/microceph-firstboot.sh: the first-boot bootstrap script
  • /usr/local/sbin/microceph-s3-roundtrip.py: the S3 round-trip check
  • /usr/share/doc/sac/MICROCEPH-COPYING.txt: the AGPL-3.0 licence text

Persistence, first boot and updates

The cluster, its data and the per-VM credentials persist across reboots on the OS disk. First boot runs once, guarded by /var/lib/sac/data/microceph-firstboot.done, and never re-bootstraps a live cluster.

unattended-upgrades applies OS security updates automatically. The MicroCeph snap is held, so it will not move Ceph major versions unattended. Review the MicroCeph release notes, then upgrade Ceph deliberately with sudo snap refresh microceph --channel=<track>.

Troubleshooting

  • First boot is still running. Watch it with journalctl -u microceph-firstboot.service -f. Bootstrap plus OSD provisioning takes a couple of minutes on first boot.
  • HEALTH_WARN briefly after boot. Placement groups settle for a short time after the OSDs come up. The cluster converges to HEALTH_OK within a minute.
  • S3 client TLS errors. The certificate is self-signed. Trust /etc/sac/tls/rgw.crt, or use your client's insecure or no-verify flag for development.
  • Cannot reach the endpoint remotely. Confirm that the NSG allows TCP 443 from your client and that you are using https:// and the VM's public IP.

Security recommendations

  • Scope the NSG. Make TCP 22 reachable only from your management network and TCP 443 only from your S3 clients.
  • Use your own certificate. For production, replace the self-signed certificate with one issued for your own DNS name, and update your clients' trust accordingly.
  • Rotate and separate keys. Rotate the RGW keys periodically with sudo microceph.radosgw-admin key create/rm. Create per-application users rather than sharing the SecureAnyCloud admin keypair.
  • Keep the OS current. unattended-upgrades is enabled. Review MicroCeph releases before you refresh the snap.

Support

SecureAnyCloud provides 24/7 support with a 24-hour response SLA for this image. This image is a repackaged open source software product, with additional charges for SecureAnyCloud support services.

MicroCeph is distributed under the GNU Affero General Public License v3.0, and Ceph under the GNU Lesser General Public License v2.1. Both names are trademarks of their respective owners. Use of the names does not imply affiliation or endorsement.

Deploy on Azure

Launch MicroCeph 19.2.3 on Ubuntu 24.04 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