Alibaba Sentinel 1.8.10 on AWS User Guide

Overview

This guide covers launching and using the Alibaba Sentinel 1.8.10 on Ubuntu 24.04 AMI from cloudimg on Amazon EC2. It is one version of the cloudimg application infrastructure listing on AWS Marketplace; you pick it as the software version when you subscribe and launch.

Sentinel is Alibaba's open source flow control library for microservices: it limits request rates, breaks circuits around slow or failing dependencies and protects a service when the host is overloaded. Services that embed the Sentinel client register with the Sentinel Dashboard, the web console this image runs. The dashboard shows each service's machines and real time metrics, and you create the flow, circuit breaking, hot parameter, system and authorisation rules there; the dashboard pushes them to the clients. This image runs the official Sentinel Dashboard 1.8.10 release on OpenJDK 17.

The cloudimg image adds:

• HTTPS from the first boot. nginx serves the dashboard on port 443 with a certificate generated on your instance's first boot (TLS 1.2 or newer). Nothing listens on port 80, and requests for a host name the instance does not serve are dropped.
• No default login. Upstream Sentinel Dashboard signs in with sentinel / sentinel. On this image first boot generates a username and a 32 character password unique to your instance and writes them to /root/sentinel-dashboard-credentials.txt; sentinel / sentinel is refused. The dashboard refuses to start at all unless a well formed, non default login is in place, because a blank login would let anyone in.
• The dashboard on loopback only. The dashboard's Java process listens on 127.0.0.1:8080 behind nginx. The dashboard's own Sentinel command port (8719), which upstream opens on every interface without authentication, is switched off. The only open ports are 22 and 443.
• Client registration from private networks only. Sentinel clients announce themselves to /registry/machine without credentials (that is how the protocol works), and the dashboard then connects back to the address they report. nginx accepts these registrations only from your private networks (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and refuses everyone else, and you can narrow the list to your application subnets (Step 7).
• Hardened defaults. The dashboard runs as its own unprivileged user in a systemd sandbox with no capabilities. The dashboard, nginx and the first boot service are all blocked from the instance metadata service, so a registered "machine" cannot point the dashboard at it; the AMI requires IMDSv2. The session cookie is HTTPS only, sign in attempts are rate limited, the dashboard's address comes from your configuration rather than from a request, and the real client address comes from the connection.
• The official release, verified, and fully patched Ubuntu 24.04 LTS at build time, with unattended security upgrades switched on (they also keep OpenJDK patched).

What is on the image: Sentinel Dashboard 1.8.10 (the official sentinel-dashboard-1.8.10.jar, checksum verified, licence in /usr/share/doc/sentinel-dashboard), OpenJDK 17 from Ubuntu, nginx, the sentinel-dashboard and sentinel-dashboard-firstboot services, Ubuntu 24.04 LTS, cloud-init and the AWS Systems Manager agent. Rules, machines and metrics are held in the dashboard's memory, as upstream designs it; your services keep their rules if the dashboard restarts.

Default user: ubuntu · Architecture: x86_64 · Recommended instance type: m5.large

Prerequisites

• An AWS account subscribed to the listing, an EC2 key pair and a VPC subnet. Put the dashboard in the same VPC as the services you want to protect (or one routed to it), because the dashboard and the clients talk to each other in both directions.
• A security group on the dashboard that allows TCP 22 (SSH) and TCP 443 (the dashboard, and client registration) from your own networks only.
• A security group on your services that lets the dashboard reach each Sentinel client's command port (TCP 8719 by default).

Step 1: Launch the instance

In the AWS Marketplace listing choose Continue to Subscribe, then Continue to Configuration, pick Alibaba Sentinel 1.8.10 on Ubuntu 24.04 as the software version and your Region, then Launch through EC2. Choose m5.large, your key pair, a subnet and a security group as above.

With the AWS CLI (replace the values in angle brackets):

aws ec2 run-instances --region <region> --image-id <ami-id-from-the-listing> \
  --instance-type m5.large --key-name <your-key-pair> \
  --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=sentinel-dashboard}]'

Step 2: Connect to your instance

ssh -i <your-key.pem> ubuntu@<public-ip>

Step 3: Check the services

First boot takes a few seconds, and the dashboard needs about fifteen seconds more to start. Then the three units are active:

systemctl is-active sentinel-dashboard-firstboot sentinel-dashboard nginx

active
active
active

The dashboard (the java process) listens on loopback only; nginx serves port 443:

sudo ss -tlnp | awk 'NR==1 || /java|nginx|sshd/' | awk '{print $1, $4, $6}' | sed -E 's/,pid=[0-9]+,fd=[0-9]+//g'

State Local Peer
LISTEN 127.0.0.1:8080 users:(("java"))
LISTEN 0.0.0.0:22 users:(("sshd"),("systemd"))
LISTEN 0.0.0.0:443 users:(("nginx"),("nginx"),("nginx"))
LISTEN [::]:22 users:(("sshd"),("systemd"))
LISTEN [::]:443 users:(("nginx"),("nginx"),("nginx"))

The release on the image and the Java runtime:

sha256sum /opt/sentinel-dashboard/lib/sentinel-dashboard.jar
unzip -p /opt/sentinel-dashboard/lib/sentinel-dashboard.jar BOOT-INF/classes/application.properties | grep '^sentinel.dashboard.version'
java -version 2>&1 | head -2

9e0d11bc30006c9f70cde982b456fc7bd03b94ec9ab5c45c034eb66b968ca19e  /opt/sentinel-dashboard/lib/sentinel-dashboard.jar
sentinel.dashboard.version=1.8.10
openjdk version "17.0.20.1" 2026-08-18
OpenJDK Runtime Environment (build 17.0.20.1+1-1-24.04-Ubuntu)

Step 4: Get your URL, username and password

sudo cat /root/sentinel-dashboard-credentials.txt

The file holds the address the dashboard is served as (your instance's public DNS name by default) and the login generated on this instance:

# Sentinel Dashboard 1.8.10 - generated on first boot by sentinel-dashboard-firstboot.service
# This login is unique to this instance; none was baked into the image, and the upstream default
# sentinel/sentinel is refused. Keep this file secret.

SENTINEL_DASHBOARD_URL=https://ec2-<public-ip-dashed>.<region>.compute.amazonaws.com/
SENTINEL_DASHBOARD_USER=admin-<8 hex characters>
SENTINEL_DASHBOARD_PASSWORD=<32 letters and digits>
#
# Open SENTINEL_DASHBOARD_URL in a browser (self-signed certificate minted on this instance's first boot)
# and sign in with the user and password above.
# Point Sentinel clients at it with:  -Dcsp.sentinel.dashboard.server=https://<this instance's private IP>
# Registration allow list:  /etc/nginx/sentinel-registry-allow.conf
# Change the login:             sudo sentinel-set-password
# Change the name it serves as: sudo sentinel-set-hostname <your-dns-name>
# User guide: https://www.cloudimg.co.uk/guides/alibaba-sentinel-1-8-10-on-ubuntu-24-04-aws/

Step 5: Sign in from your browser

Open SENTINEL_DASHBOARD_URL in your browser. The certificate is self signed (generated on your instance), so accept the browser warning once, or install your own certificate (Step 8). The dashboard's interface is in Chinese, as upstream ships it: 用户 is the username, 密码 the password and 登录 signs you in.

Signed in, the left hand menu lists every application that has registered, with the count of healthy machines out of all machines in brackets. Under an application you find 实时监控 (real time monitoring), 簇点链路 (the resources the client has seen), 流控规则 (flow rules), 熔断规则 (circuit breaking rules), 热点规则 (hot parameter rules), 系统规则 (system rules), 授权规则 (authorisation rules), 集群流控 (cluster flow control) and 机器列表 (the machine list). 注销 at the top right signs you out.

Step 6: Connect your services

Each service that uses the Sentinel client library needs three Java system properties (or the same keys in its sentinel.properties). Use the dashboard's private IP address and https://; the Sentinel client accepts the dashboard's self signed certificate:

-Dcsp.sentinel.dashboard.server=https://<dashboard-private-ip>
-Dproject.name=<your-service-name>
-Dcsp.sentinel.api.port=8719

The client sends a heartbeat to the dashboard every ten seconds, and the dashboard connects back to the client's command port (8719 above) to read metrics and push rules, so the client's security group must allow TCP 8719 from the dashboard. A heartbeat is a plain HTTPS POST. This one, sent from the instance's own private address the way a client would, registers a machine called demo-service:

H=$(sudo sed -n 's#^SENTINEL_DASHBOARD_URL=https://\([^/]*\)/#\1#p' /root/sentinel-dashboard-credentials.txt)
PRIV=$(hostname -I | awk '{print $1}')
curl -sk --resolve "$H:443:$PRIV" -X POST "https://$H/registry/machine" \
  --data "app=demo-service&ip=$PRIV&port=8719&hostname=$(hostname)&v=1.8.10&version=$(date +%s%3N)"; echo

{"success":true,"code":0,"msg":"success","data":null}

The machine appears straight away under demo-service, 机器列表 (machine list), as healthy (健康):

Rules are created per application under 流控规则 and the other rule pages; 新增流控规则 adds a flow rule for a resource and the dashboard pushes it to the client's command port. A machine whose heartbeats stop is counted as unhealthy after about a minute (here demo-service (0/1), because the demonstration heartbeat above was sent only once), and rules can be pushed only to machines the dashboard can reach:

Rules live in the dashboard's memory and in each client, as upstream designs it. To keep rules across client restarts, configure a rule data source in your services (for example Nacos, Apollo, ZooKeeper or a file), as described in the Sentinel documentation.

Step 7: Security checks

The dashboard answers over HTTPS, a request for a host name the instance does not serve gets no answer (000), nothing listens on port 80, the API refuses a caller that has not signed in, and the upstream default login is refused:

H=$(sudo sed -n 's#^SENTINEL_DASHBOARD_URL=https://\([^/]*\)/#\1#p' /root/sentinel-dashboard-credentials.txt)
curl -sk -o /dev/null -w 'dashboard page: %{http_code}\n' --resolve "$H:443:127.0.0.1" "https://$H/"
curl -sk -o /dev/null -w 'unknown host name: %{http_code}\n' -H 'Host: example.com' https://127.0.0.1/ || true
curl -s -o /dev/null -w 'port 80: %{http_code}\n' http://127.0.0.1/ || true
curl -sk -o /dev/null -w 'API without signing in: %{http_code}\n' --resolve "$H:443:127.0.0.1" "https://$H/app/briefinfos.json"
curl -sk --resolve "$H:443:127.0.0.1" -X POST "https://$H/auth/login" --data 'username=sentinel&password=sentinel'; echo

dashboard page: 200
unknown host name: 000
port 80: 000
API without signing in: 401
{"success":false,"code":-1,"msg":"Invalid username or password","data":null}

Your own login works from the command line too; the password is passed to curl from a file, so it never appears on a command line:

H=$(sudo sed -n 's#^SENTINEL_DASHBOARD_URL=https://\([^/]*\)/#\1#p' /root/sentinel-dashboard-credentials.txt)
U=$(sudo sed -n 's/^SENTINEL_DASHBOARD_USER=//p' /root/sentinel-dashboard-credentials.txt)
PWF=$(mktemp); JAR=$(mktemp)
sudo sed -n 's/^SENTINEL_DASHBOARD_PASSWORD=//p' /root/sentinel-dashboard-credentials.txt | tr -d '\n' > "$PWF"
curl -sk --resolve "$H:443:127.0.0.1" -c "$JAR" -X POST "https://$H/auth/login" --data-urlencode "username=$U" --data-urlencode "password@$PWF" | grep -o '"success":true'
curl -sk -o /dev/null -w 'API signed in: %{http_code}\n' --resolve "$H:443:127.0.0.1" -b "$JAR" "https://$H/app/briefinfos.json"
rm -f "$PWF" "$JAR"

"success":true
API signed in: 200

Registration from the internet is refused. The allow list in /etc/nginx/sentinel-registry-allow.conf holds loopback and the private ranges; every other address gets 403. From a computer outside your VPC (with port 443 open to it), a registration attempt looks like this:

curl -sk -o /dev/null -w '%{http_code}\n' -X POST https://<public-ip>/registry/machine --data 'app=demo-service&ip=203.0.113.10&port=8719'
403

grep -v '^#' /etc/nginx/sentinel-registry-allow.conf

allow 127.0.0.1;
allow ::1;
allow 10.0.0.0/8;
allow 172.16.0.0/12;
allow 192.168.0.0/16;

Who can reach /registry/machine. Registration needs no credentials, because Sentinel clients have no way to send them, and the dashboard connects back to whatever address a registration reports. On this image the endpoint is reachable from your VPC's private ranges only. If other teams or tenants share the VPC, restrict it further: allow only your application subnets in the dashboard's security group, in the allow list file, or both.

To narrow it to your application subnets, replace the 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 lines with one allow <cidr>; line per subnet (keep the loopback lines), then reload nginx:

sudo nano /etc/nginx/sentinel-registry-allow.conf
sudo nginx -t && sudo systemctl reload nginx

The certificate was generated on this instance and names its own addresses:

H=$(sudo sed -n 's#^SENTINEL_DASHBOARD_URL=https://\([^/]*\)/#\1#p' /root/sentinel-dashboard-credentials.txt)
echo | openssl s_client -connect 127.0.0.1:443 -servername "$H" 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName

subject=CN = ec2-<public-ip-dashed>.<region>.compute.amazonaws.com, O = cloudimg
X509v3 Subject Alternative Name:
    DNS:ec2-<public-ip-dashed>.<region>.compute.amazonaws.com, IP Address:<public-ip>, IP Address:<private-ip>, DNS:ip-<private-ip-dashed>.ec2.internal, IP Address:127.0.0.1, DNS:localhost

The dashboard runs unprivileged in a sandbox, bound to loopback with its own command port switched off, and neither it, nginx nor the first boot service can reach the instance metadata service. First boot proves that on every instance:

systemctl show sentinel-dashboard -p User -p ProtectSystem -p NoNewPrivileges -p IPAddressDeny
systemctl show nginx -p IPAddressDeny
tr '\0' '\n' < /proc/$(systemctl show -p MainPID --value sentinel-dashboard)/cmdline | grep -E '^-D(server.address|server.port|csp.sentinel.api.port)|^-Xm'
sudo journalctl -u sentinel-dashboard-firstboot -o cat --no-pager | grep -E 'IMDS|Serving'

IPAddressDeny=fd00:ec2::254/128 169.254.169.254/32 168.63.129.16/32
User=sentinel
ProtectSystem=strict
NoNewPrivileges=yes
IPAddressDeny=fd00:ec2::254/128 169.254.169.254/32 168.63.129.16/32
-Xms256m
-Xmx1024m
-Dserver.address=127.0.0.1
-Dserver.port=8080
-Dcsp.sentinel.api.port=-1
[<timestamp>] sentinel-firstboot: IMDS_EGRESS_BLOCKED: 169.254.169.254 refused inside sentinel-dashboard-firstboot.service
[<timestamp>] sentinel-firstboot: Serving as ec2-<public-ip-dashed>.<region>.compute.amazonaws.com

nginx passes the dashboard a fixed host name and the real client address from the connection, never values a client sent:

grep -E 'proxy_set_header (Host|X-Forwarded-For|X-Real-IP)' /etc/nginx/sites-available/cloudimg-sentinel

    proxy_set_header Host $sentinel_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $remote_addr;

Step 8: Your own DNS name and certificate

Point a DNS record at the instance, then set the name the dashboard is served as. This mints a new self signed certificate for the name (plus the instance's own addresses), updates nginx and the URL in /root/sentinel-dashboard-credentials.txt, and keeps the name across reboots:

sudo sentinel-set-hostname <your-domain>

To use a certificate from your own certificate authority instead, copy it over the generated pair and reload nginx (running sentinel-set-hostname again replaces it with a self signed one):

sudo install -m 0644 <your-domain>.crt /etc/nginx/ssl/sentinel.crt
sudo install -m 0600 <your-domain>.key /etc/nginx/ssl/sentinel.key
sudo nginx -t && sudo systemctl reload nginx

Step 9: Change the login

sentinel-set-password writes a new login to /etc/sentinel-dashboard/auth.env (readable by root only, handed to the dashboard by systemd, never on a command line), records it in /root/sentinel-dashboard-credentials.txt and restarts the dashboard. Run it without arguments for a new random password, pass your own (24 to 64 letters and digits) on stdin, or change the username with --user:

sudo sentinel-set-password
printf '%s\n' '<your-new-password>' | sudo sentinel-set-password --stdin
sudo sentinel-set-password --user <new-username>

Step 10: Operations

• Memory. The dashboard's heap is capped at 1 GiB (SENTINEL_HEAP_MAX in /etc/sentinel-dashboard/sentinel-dashboard.conf), which suits m5.large and t3.medium. For many applications and machines, raise it and run sudo systemctl restart sentinel-dashboard.
• Logs. journalctl -u sentinel-dashboard and /var/log/sentinel-dashboard/sentinel-dashboard.log; nginx logs every request with the real client address in /var/log/nginx/access.log. The dashboard logs an error each time it cannot reach a registered machine's command port, which is normal for machines that have gone away.
• Restarts. Machines re-register within ten seconds of a dashboard restart; rules already pushed stay in the clients.
• Updates. Unattended upgrades apply Ubuntu and OpenJDK security updates. The dashboard itself is the jar in /opt/sentinel-dashboard/lib.

Support

cloudimg provides 24/7 technical support for this image by email and live chat: deployment, HTTPS and certificates, connecting your services, rules and troubleshooting. Contact support@cloudimg.co.uk.

Sentinel is an open source project of Alibaba under the Apache License 2.0. Alibaba is a trademark of Alibaba Group Holding Limited. cloudimg is not affiliated with or endorsed by Alibaba Group or the Sentinel project.