CentOS Stream 10 ARM64

Option A: Azure Portal

• Go to the Azure Marketplace and search for "CentOS Stream 10 Arm64 SecureAnyCloud".
• Select the image and click Create.
• Configure the basics:
• Subscription: select your Azure subscription.
• Resource Group: create a new one or select an existing one.
• Virtual Machine Name: enter a name for your VM.
• Region: select a region that offers Arm sizes.
• Size: Standard_D2ps_v6 is recommended (an Arm64 size).
• Under Administrator Account, select SSH public key and enter your key.
• Under Inbound Port Rules, allow SSH (port 22).
• Click Review + Create, then Create.

Option B: Azure CLI

Run this on your own workstation. Substitute your resource group, VM name and preferred region. Accept the Marketplace terms once per subscription, then create the machine:

az vm image terms accept --urn sac1647283583153:centos-stream-10-arm64:default:latest
az vm create \
  --resource-group myResourceGroup \
  --name my-centos-stream-10-arm64-vm \
  --image sac1647283583153:centos-stream-10-arm64:default:latest \
  --size Standard_D2ps_v6 \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

The --size must be an Arm64 size (Standard_D2ps_v6 above). Azure rejects an x86 size for an Arm image at create time.

Run these on your own workstation, not on the VM. Find the public IP, then connect:

az vm show --resource-group myResourceGroup --name my-centos-stream-10-arm64-vm --show-details --query publicIps -o tsv ssh azureuser@<vm-ip>

There is no password to enter. If SSH asks for one, your client is not offering the key that you supplied at create time.

Check that the machine is CentOS Stream 10:

cat /etc/centos-release

CentOS Stream release 10 (Coughlan)

The os-release fields carry the same identity in machine-readable form. Note that VERSION_ID is 10 with no minor component, because CentOS Stream does not have minor releases:

grep -E '^(NAME|VERSION|ID|VERSION_ID|PLATFORM_ID)=' /etc/os-release

NAME="CentOS Stream" VERSION="10 (Coughlan)" ID="centos" VERSION_ID="10" PLATFORM_ID="platform:el10"

/etc/redhat-release records the RHEL family lineage and reads the same on CentOS Stream:

cat /etc/redhat-release

CentOS Stream release 10 (Coughlan)

Confirm the kernel, the architecture and the page size. aarch64 is the proof this is the Arm build, and 4096 is the page size this release ships:

uname -srm getconf PAGESIZE

Linux 6.12.0-267.el10.aarch64 aarch64 4096

The 64k page size kernel is an optional package on EL10 and is deliberately not installed. The page size above therefore does not change on a kernel update:

rpm -q kernel-64k || echo "(kernel-64k absent - this image is the standard 4k page size build)"

package kernel-64k is not installed (kernel-64k absent - this image is the standard 4k page size build)

Confirm the processor. On an Azure Arm size the BIOS model name identifies the Cobalt 100 host and the core is an Arm Neoverse N2:

lscpu | grep -E '^(Architecture|Vendor ID|Model name|BIOS Model name):'

Architecture: aarch64 Vendor ID: ARM Model name: Neoverse-N2 BIOS Model name: Cobalt 100 None CPU @ 3.4GHz

The image is fully patched at capture. dnf check-update exits 0 when nothing is pending and 100 when updates are waiting, so you want an exit code of 0:

sudo dnf -q check-update >/dev/null 2>&1; echo "exit=$?"

exit=0

Confirm nothing is waiting on a reboot:

sudo dnf needs-restarting -r

No core libraries or services have been updated since boot-up. Reboot should not be necessary.

The update path is intact. BaseOS carries the core operating system. AppStream carries the application packages and the security updates that reach them. Extras carries the CentOS-specific additions:

sudo dnf repolist --enabled

repo id repo name appstream CentOS Stream 10 - AppStream baseos CentOS Stream 10 - BaseOS extras-common CentOS Stream 10 - Extras packages

A single kernel is installed, the one the machine is running:

rpm -q kernel-core

kernel-core-6.12.0-267.el10.aarch64

Automatic updates

dnf-automatic is installed and its timer is enabled, so the machine applies security updates on its own:

systemctl is-enabled dnf-automatic.timer

enabled

It runs daily at 06:00 with up to an hour of random delay, so a fleet does not hit the mirrors at the same second:

systemctl cat dnf-automatic.timer | grep -E 'OnCalendar|RandomizedDelaySec'

OnCalendar=*-*-* 6:00 RandomizedDelaySec=60m

The policy downloads and applies security updates, and never reboots the machine by itself. An unannounced reboot on a production machine is worse than a deferred kernel, so you decide when to reboot:

grep -E '^(apply_updates|upgrade_type|download_updates|reboot) ' /etc/dnf/automatic.conf

upgrade_type = security download_updates = yes apply_updates = yes reboot = never

To apply every update rather than only security fixes, set upgrade_type to default in /etc/dnf/automatic.conf. To take all pending updates by hand at any time, run sudo dnf -y upgrade.

SELinux is enforcing, the CentOS default. The setting is persisted in /etc/selinux/config, so it survives reboots:

getenforce

Enforcing

The root account password is locked. An L in the second field confirms it:

sudo passwd -S root

root L 2009-12-22 -1 -1 -1 -1

No account on the image ships a usable password. This command prints the name of every account that has one, and it prints nothing:

sudo awk -F: '($2 !~ /^[!*]/) && ($2 != "") {print $1}' /etc/shadow

Read the SSH policy from the daemon's effective configuration rather than from the file. Drop-ins and includes can override what you see in /etc/ssh/sshd_config:

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication|kbdinteractiveauthentication) '

permitrootlogin without-password pubkeyauthentication yes passwordauthentication no kbdinteractiveauthentication no

without-password is the older name for prohibit-password: root may not log in with a password. Root's password is locked and root has no authorized_keys, so there is no root login on a machine you launch.

There is no swap on the operating system disk, so nothing pages onto the OS disk and nothing writes secrets to it:

swapon --show

SSH is the only service listening off the machine. Port 22 is the entire TCP listener set. The only UDP socket is chrony's on the loopback address, which is not reachable from off the machine:

ss -tln

State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 0.0.0.0:22 0.0.0.0:* LISTEN 0 128 [::]:22 [::]:*

ss -uln

State Recv-Q Send-Q Local Address:Port Peer Address:Port UNCONN 0 0 127.0.0.1:323 0.0.0.0:* UNCONN 0 0 [::1]:323 [::]:*

The upstream CentOS Stream cloud image ships with the Cockpit web console enabled and listening on port 9090. This image removes it at the package level, so it cannot be re-enabled by accident:

rpm -q cockpit-ws || echo "(cockpit-ws absent - nothing listens on 9090)"

package cockpit-ws is not installed (cockpit-ws absent - nothing listens on 9090)

rpcbind arrives as a dependency of the NFS client tooling. Both its socket and its service are disabled, so nothing binds port 111:

systemctl is-enabled rpcbind.socket rpcbind.service || true

disabled disabled

The Azure Linux Agent is running and enabled at boot. It provides VM extensions, the serial console, password reset and boot diagnostics:

systemctl is-active waagent
systemctl is-enabled waagent

active enabled

The Azure guest stack is installed from the CentOS repositories:

rpm -q WALinuxAgent cloud-init chrony

WALinuxAgent-2.14.0.1-3.el10.noarch cloud-init-24.4-7.el10.1.noarch chrony-4.8-2.el10.aarch64

cloud-init ran to completion on this boot. It injected your SSH key, set the hostname and grew the root filesystem:

cloud-init status

status: done

The serial console is on ttyAMA0, the Arm PL011 UART. This matters on Arm. The upstream cloud image inherits the x86 default of ttyS0, a 16550 UART that does not exist on Cobalt 100, so the Azure serial console and boot diagnostics would show nothing at all. This image corrects the setting, and the fix persists across kernel upgrades:

grep -o 'console=ttyAMA0[^ ]*' /proc/cmdline

console=ttyAMA0,115200n8

Time is synchronised against the Azure host clock by chronyd, and the machine is on UTC:

systemctl is-active chronyd

active

timedatectl | grep -E 'Time zone|System clock|NTP service'

Time zone: UTC (UTC, +0000) System clock synchronized: yes NTP service: active

The disk layout is flat: a 200 MB EFI system partition and an XFS root that cloud-init grows to the full size of the operating system disk on first boot. There is no LVM. sr0 is the small read-only ISO that Azure attaches to pass provisioning data to the machine. It is not storage you use:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT

NAME SIZE TYPE FSTYPE MOUNTPOINT sda 30G disk ├─sda1 200M part vfat /boot/efi └─sda2 29.8G part xfs / sr0 630K rom

df -h /

Filesystem Size Used Avail Use% Mounted on /dev/sda2 30G 2.2G 28G 8% /

To use a larger operating system disk, set the size when you create the VM, or resize the disk in the portal and reboot. The root filesystem grows to match automatically.

There is no host firewall in this image. firewalld is not installed:

rpm -q firewalld || echo "(firewalld absent - the Azure NSG is your only firewall)"

package firewalld is not installed (firewalld absent - the Azure NSG is your only firewall)

The only nftables rules on the machine are the three that the Azure Linux Agent installs to protect the Azure wire server endpoint 168.63.129.16. They are present on every Azure Linux image and only affect traffic to that one address. They do not filter anything you serve. sudo nft list ruleset shows them:

table ip security { chain OUTPUT { type filter hook output priority 150; policy accept; ip daddr 168.63.129.16 tcp dport 53 counter packets 0 bytes 0 accept ip daddr 168.63.129.16 ip protocol tcp skuid 0 counter packets 1133 bytes 353881 accept ip daddr 168.63.129.16 ip protocol tcp ct state invalid,new counter packets 0 bytes 0 drop } }

Your Azure Network Security Group is the firewall. It sits in front of the network interface and drops traffic before it reaches the machine, so it is the right place to control inbound access. Open only the ports you serve, and restrict the SSH source range to the addresses you administer from.

To add a rule, run this on your own workstation:

az network nsg rule create \
  --resource-group myResourceGroup \
  --nsg-name my-centos-stream-10-arm64-vmNSG \
  --name allow-https \
  --priority 1010 \
  --destination-port-ranges 443 \
  --access Allow --protocol Tcp

If you also want a host firewall, install it with sudo dnf install -y firewalld and enable it with sudo systemctl enable --now firewalld. Open SSH before you start it, or you will lock yourself out.

AppStream carries the application packages. Everything in the repositories is built for Arm, so dnf resolves aarch64 packages automatically, with nothing extra to configure:

sudo dnf -q list --available nginx 2>/dev/null | tail -2

Available Packages nginx.aarch64 2:1.26.3-15.el10 appstream

Install a package and enable it in the usual way. For example, run sudo dnf install -y nginx followed by sudo systemctl enable --now nginx, then open the port in your Network Security Group.

To add another administrator, create the account with sudo adduser <name>. Add it to the wheel group with sudo usermod -aG wheel <name>. Then copy your public key into /home/<name>/.ssh/authorized_keys, with mode 600 on the file and mode 700 on the .ssh directory, both owned by that user.

The image ships with no human accounts at all, so the administrator you named at create time is the only login until you add one.