Checkmk

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet plus subnet in the target region.

Standard_B2s (2 vCPU / 4 GiB RAM) is a sensible starting point. Size up for more monitored hosts, more services or longer history retention.

In the NSG, allow inbound 22/tcp from your management network and 443/tcp for the web interface. Port 80 is only used for health probes and to redirect browsers to HTTPS.

The web interface is served over HTTPS with a self-signed certificate that is regenerated per VM, so your browser shows a certificate warning on the first visit. For production, place your own certificate, or a load balancer with a managed certificate, in front of the appliance.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Checkmk 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 select Review + create, and then Create.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:checkmk-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name checkmk \
  --image sac1647283583153:checkmk-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Then open port 443 for the web interface:

az vm open-port --resource-group <your-rg> --name checkmk --port 443

Step 3 - Confirm the services are running

SSH in as azureuser and confirm that the system Apache and the Checkmk site are active. Checkmk's own omd.service starts the site on every boot, so a single command reports both Apache and the site as active.

The site's own processes (its Nagios core, RRD cache, site Apache and more) run under the cmk site user. The system Apache proxies them on ports 80 and 443.

systemctl is-active apache2 omd

sudo omd status cmk | grep -iE 'Overall|nagios|apache|rrdcached'

sudo ss -tlnp | grep -E ':80 |:443 '

Step 4 - Retrieve the per-VM administrator password

The administrator password is generated uniquely on the first boot of every VM and written to a root-only file. Read it over SSH:

sudo cat /root/checkmk-credentials.txt

The file records the site URL, the cmkadmin user name and the per-VM password. Keep it somewhere safe.

Step 5 - Sign in to the Checkmk web interface

Open https://<your-vm-public-ip>/cmk/ in a browser. The certificate is self-signed and unique to your VM, so your browser warns on the first visit. Accept the warning to continue. Sign in as cmkadmin with the password from the previous step.

After you sign in, you land on the main monitoring dashboard. It has panels for host and service statistics and for current and recent problems. On a fresh appliance these read zero until you add your first host.

Step 6 - Add your first host

Go to Setup then Hosts, and choose Add host to the monitoring. Give the host a name and its IP address or resolvable host name. Then save, and run a service discovery so Checkmk finds what to monitor.

Most hosts are monitored with the Checkmk agent (installed on the target), with SNMP, or through one of the built-in API integrations. After you add a host, activate your pending changes to put it into monitoring.

Step 7 - Monitor your hosts and services

Under Monitor, the All hosts view lists every monitored host with its current state. The service views break out each check. From here you can acknowledge problems, schedule downtimes and filter by any attribute. On a fresh appliance the list is empty until you complete Step 6.

Step 8 - The secured default account (no default login)

Creating a Checkmk site normally generates a cmkadmin account with a password printed once at creation time. In the SecureAnyCloud image, that creation-time password is discarded and never shipped.

On the first boot of every VM, the cmkadmin password is rotated to a unique per-VM secret, written to the root-only credentials file from Step 4. The account is kept a normal interactive administrator (not an automation user), so the web login works while no known or blank credential is ever exposed.

You can prove the round trip on the VM. The per-VM password signs in and establishes a session, and a wrong password is rejected.

sudo bash /usr/local/sbin/checkmk-cred-roundtrip.sh

Step 9 - Confirm the edition, version and HTTPS

This image ships the Checkmk Raw edition, which is the free and open-source edition licensed under the GNU GPL version 2. You can confirm the edition and version, the HTTPS login page and the health endpoint directly on the VM:

omd version

curl -ksI https://127.0.0.1/cmk/check_mk/login.py | head -1

curl -sI http://127.0.0.1/healthz | head -1

Where your data lives

The monitoring site and everything in it live under /omd/sites/cmk on the OS disk. That includes your host and service configuration, the collected metrics and RRD databases, the site logs and the web configuration. The OS disk is captured into the image and re-provisioned on every VM.

Back up that directory (or use Checkmk's own backup under Setup then Backup) to protect your configuration and history. The per-VM administrator credentials are in /root/checkmk-credentials.txt (root only).

Licence

Checkmk Raw edition is free and open-source software licensed under the GNU General Public License, version 2 (GPL-2.0). The commercial Checkmk editions (Pro, Ultimate and Cloud) are not included in this image.

SecureAnyCloud is not affiliated with, endorsed by, or sponsored by Checkmk GmbH. Checkmk is a trademark of Checkmk GmbH, used here only to identify the open-source software packaged in this image.

Support

SecureAnyCloud provides this image with 24/7 support. If you have questions about deploying or operating Checkmk on Azure, contact us at sales@secureanycloud.com.

Deploy on Azure

Launch Checkmk 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

Edition and licence

This AMI ships Checkmk Raw Edition (CRE) only, the open-source edition licensed under the GNU GPL-2.0. The installed package is check-mk-community, and omd version reports the .community build. No commercial Checkmk Enterprise, Cloud or MSP component is bundled.

Secure by default - no shipped credentials

The image ships with no known administrator password. When the Checkmk site is created, the installer prints a random cmkadmin password. That password is discarded and never shipped.

On first boot, a unique cmkadmin password is generated for this specific instance and written to /root/checkmk-credentials.txt. The GUI is served only over HTTPS. Plain HTTP returns a health check and redirects to HTTPS.

Connecting to your instance

Connect over SSH on port 22 with the EC2 key pair you launched with. For Ubuntu 24.04, the SSH login user is ubuntu, for example: ssh -i your-key.pem ubuntu@<public-ip>

Replace <public-ip> with your instance's public IPv4 address, or with its private address if you reach it over a VPN or Direct Connect.

Retrieve your per-instance admin password

The cmkadmin password is generated uniquely on this instance at first boot. Read it over SSH:

sudo grep '^CHECKMK_ADMIN_PASSWORD=' /root/checkmk-credentials.txt

The same file records the login URL and username:

sudo cat /root/checkmk-credentials.txt

Sign in to the Checkmk GUI

Open the GUI in your browser over HTTPS. The certificate is self-signed and regenerated per instance, so your browser warns on the first visit:

https://<public-ip>/cmk/

Sign in as cmkadmin with the password from the credentials file.

After you sign in, you land on the main dashboard. It summarises host and service statistics, current problems and recent events:

Verify the security posture

The commands below run against the site's REST API on the instance itself. First confirm that an unauthenticated request and a wrong password are both refused. Then confirm that the real per-instance password authenticates:

SITE=cmk API="https://127.0.0.1/${SITE}/check_mk/api/1.0"
PW=$(sudo grep '^CHECKMK_ADMIN_PASSWORD=' /root/checkmk-credentials.txt | cut -d= -f2-)
U=$(curl -ks -o /dev/null -w '%{http_code}' "${API}/version")
W=$(curl -ks -o /dev/null -w '%{http_code}' -H "Authorization: Bearer cmkadmin WRONGwrongWRONG" "${API}/version")
C=$(curl -ks -o /dev/null -w '%{http_code}' -H "Authorization: Bearer cmkadmin ${PW}" "${API}/version")
echo "unauthenticated=${U} wrong-password=${W} correct-per-instance-password=${C}" [ "$U" = 401 ] && [ "$W" = 401 ] && [ "$C" = 200 ] || {
echo "error: security posture assertion failed"; exit 1; }
echo "SECURITY_POSTURE_OK"

The first two return 401 and only the last returns 200. The image ships no default or blank credential on the network-reachable GUI.

Create an automation user

Drive the Checkmk REST API with a dedicated automation user. Create one as cmkadmin and commit it by activating changes. The generated secret is stored (root-only) so the following steps can use it:

SITE=cmk API="https://127.0.0.1/${SITE}/check_mk/api/1.0"
PW=$(sudo grep '^CHECKMK_ADMIN_PASSWORD=' /root/checkmk-credentials.txt | cut -d= -f2-) SECRET="CmkAuto$(openssl rand -hex 10)"
# create the automation user (idempotent: reset its secret if it already exists) code=$(curl -ks -o /dev/null -w '%{http_code}' -X POST "${API}/domain-types/user_config/collections/all" \
  -H "Authorization: Bearer cmkadmin ${PW}" -H 'Content-Type: application/json' \
  -d "{\"username\":\"automation\",\"fullname\":\"sac automation\",\"roles\":[\"admin\"],\"auth_option\":{\"auth_type\":\"automation\",\"secret\":\"${SECRET}\"}}") if [ "$code" != "200" ]; then
ETAG=$(curl -ks -D - -o /dev/null -H "Authorization: Bearer cmkadmin ${PW}" "${API}/objects/user_config/automation" | awk -F': ' 'tolower($1)=="etag"{gsub(/\r/,"");print $2}')
curl -ks -o /dev/null -X PUT "${API}/objects/user_config/automation" \
  -H "Authorization: Bearer cmkadmin ${PW}" -H 'Content-Type: application/json' ${ETAG:+-H "If-Match: ${ETAG}"} \
  -d "{\"auth_option\":{\"auth_type\":\"automation\",\"secret\":\"${SECRET}\"}}" fi curl -ks -o /dev/null -w 'commit user (activate) -> HTTP %{http_code}\n' -X POST "${API}/domain-types/activation_run/actions/activate-changes/invoke" \
  -H "Authorization: Bearer cmkadmin ${PW}" -H 'Content-Type: application/json' -H 'If-Match: *' -d "{\"redirect\":false,\"sites\":[\"${SITE}\"]}"
sudo install -m 600 /dev/null /root/.cmk-automation-secret printf '%s' "${SECRET}" | sudo tee /root/.cmk-automation-secret >/dev/null
AV=$(curl -ks -o /dev/null -w '%{http_code}' -H "Authorization: Bearer automation ${SECRET}" "${API}/version")
echo "automation secret authenticates -> HTTP ${AV}" [ "$AV" = 200 ] || {
echo "error: automation user secret did not authenticate"; exit 1; }
echo "AUTOMATION_USER_OK"

The final check returns 200, which proves that the per-instance automation secret works against the REST API.

Add your first host with the Checkmk agent

Install and register the bundled Checkmk agent on the instance. Then add localhost as a monitored host and discover its services, all through the automation user's REST secret:

SITE=cmk API="https://127.0.0.1/${SITE}/check_mk/api/1.0"
SECRET=$(sudo cat /root/.cmk-automation-secret) AUTH="Authorization: Bearer automation ${SECRET}"
# install the bundled Checkmk agent on this host
AGENT=$(ls /opt/omd/versions/*/share/check_mk/agents/check-mk-agent_*_all.deb | head -1) sudo dpkg --install "${AGENT}" >/dev/null 2>&1; echo "agent installed"
sudo systemctl enable --now check-mk-agent.socket >/dev/null 2>&1
# add the host, then register the agent (TLS) so the server can read it curl -ks -o /dev/null -w 'add host localhost -> HTTP %{http_code}\n' -X POST "${API}/domain-types/host_config/collections/all" \
  -H "${AUTH}" -H 'Content-Type: application/json' -d '{"folder":"/","host_name":"localhost","attributes":{"ipaddress":"127.0.0.1"}}'
sudo cmk-agent-ctl register --server localhost --site ${SITE} --user automation --password "${SECRET}" --hostname localhost --trust-cert >/dev/null 2>&1 && echo "agent registered"
# discover services and activate the changes curl -ks -o /dev/null -w 'service discovery -> HTTP %{http_code}\n' -X POST "${API}/domain-types/service_discovery_run/actions/start/invoke" \
  -H "${AUTH}" -H 'Content-Type: application/json' -d '{"host_name":"localhost","mode":"tabula_rasa"}' for i in $(seq 1 20); do s=$(curl -ks -H "${AUTH}" "${API}/objects/service_discovery_run/localhost" | python3 -c "import json,sys;print(json.load(sys.stdin).get('extensions',{}).get('state',''))" 2>/dev/null) [ "$s" = "finished" ] && { echo "discovery finished"; break; }; sleep 3 done curl -ks -o /dev/null -w 'activate changes -> HTTP %{http_code}\n' -X POST "${API}/domain-types/activation_run/actions/activate-changes/invoke" \
  -H "${AUTH}" -H 'Content-Type: application/json' -H 'If-Match: *' -d "{\"redirect\":false,\"sites\":[\"${SITE}\"]}"

You can see the host and its discovered services in Setup > Hosts:

Confirm real monitoring data

After activation, the Checkmk core schedules the first checks. Poll the REST API until a known service has been checked and reports a real state:

SITE=cmk API="https://127.0.0.1/${SITE}/check_mk/api/1.0"
SECRET=$(sudo cat /root/.cmk-automation-secret) AUTH="Authorization: Bearer automation ${SECRET}" for i in $(seq 1 30); do
OUT=$(curl -ks -H "${AUTH}" "${API}/domain-types/service/collections/all?host_name=localhost&columns=description&columns=state&columns=has_been_checked&columns=plugin_output")
DONE=$(printf '%s' "$OUT" | python3 -c " import json,sys m={0:'OK',1:'WARN',2:'CRIT',3:'UNKNOWN'} d=json.load(sys.stdin); hit=False for s in d.get('value',[]): e=s.get('extensions',{}) if e.get('has_been_checked')==1 and (e.get('description') in ('Check_MK','Check_MK Agent','Memory','Uptime') or 'Filesystem' in str(e.get('description',''))): print('SERVICE %-16s STATE=%-4s | %s' % (e.get('description'), m.get(e.get('state'),e.get('state')), str(e.get('plugin_output',''))[:60])) hit=True print('ROUNDTRIP_OK' if hit else 'waiting') " 2>/dev/null)
echo "$DONE" | grep -q ROUNDTRIP_OK && {
echo "$DONE"; break; } sleep 5 done
echo "$DONE" | grep -q ROUNDTRIP_OK || {
echo "error: no known service reported a real state in time"; exit 1; }

When it prints ROUNDTRIP_OK alongside services such as Check_MK Agent, Memory or Uptime in an OK state with real plugin output, your monitoring round trip is complete. The live service list, with states and metric graphs, is under Monitor > All hosts > localhost:

Managing the services

Two systemd units keep the appliance running:

systemctl status apache2 --no-pager sudo omd status cmk

• apache2.service is the system reverse proxy that terminates TLS on port 443 and proxies /cmk/.
• omd.service is Checkmk's native unit that starts the monitoring site at boot.

Using a CA-signed certificate

The image ships a per-instance self-signed certificate at /etc/ssl/sac/checkmk.crt (key checkmk.key). To use your own CA-signed or ACM-issued certificate, replace those two files with your certificate and private key, then reload Apache:

sudo cp your-fullchain.pem /etc/ssl/sac/checkmk.crt
sudo cp your-privatekey.pem /etc/ssl/sac/checkmk.key
sudo systemctl reload apache2

For a public domain, point a DNS record at your instance (or a load balancer in front of it) and issue the certificate for your-domain before installing it.

Support

SecureAnyCloud provides 24/7 technical support for this AMI by email and live chat. Support covers deployment, upgrades, TLS termination, agent registration and notification integrations. Email sales@secureanycloud.com with your AWS Marketplace subscription details.

Checkmk is a trademark of Checkmk GmbH. SecureAnyCloud is not affiliated with, endorsed by, or sponsored by Checkmk GmbH. The name is used nominatively to identify the open-source software packaged in this image.

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com