AlmaLinux 10 Lvm

Option A: Azure Portal

• Open the Azure Marketplace and search for "AlmaLinux 10 LVM SecureAnyCloud".
• Select the image and choose Create.
• On the Basics tab, configure the following:
  • 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 your preferred region
  • Size: Standard_B2s is recommended
• Under Administrator Account, select SSH public key and enter your key.
• Under Disks, keep the default 30 GB operating system disk or choose a larger size. Step 4 shows how to claim the extra space.
• Under Inbound Port Rules, allow SSH (port 22).
• Select Review + Create, then Create.

Option B: Azure CLI

Run these commands 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:almalinux-10-lvm:default:latest
az vm create \
  --resource-group myResourceGroup \
  --name my-almalinux-10-lvm-vm \
  --image sac1647283583153:almalinux-10-lvm:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Add --os-disk-size-gb 64 (or any size above 30) to start with a larger operating system disk.

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

az vm show --resource-group myResourceGroup --name my-almalinux-10-lvm-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 you supplied at create time.

Check that the machine is AlmaLinux 10:

cat /etc/almalinux-release

AlmaLinux release 10.2 (Lavender Lion)

The os-release fields carry the same information in a machine-readable form, which configuration management tools read:

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

NAME="AlmaLinux" VERSION="10.2 (Lavender Lion)" ID="almalinux" VERSION_ID="10.2" PLATFORM_ID="platform:el10"

The distribution itself asserts its RHEL compatibility lineage, and the kernel is the AlmaLinux 10 build for x86_64:

cat /etc/redhat-release uname -srm

AlmaLinux release 10.2 (Lavender Lion) Linux 6.12.0-211.53.1.el10_2.x86_64 x86_64

AlmaLinux 10 for x86_64 is compiled for the x86-64-v3 processor level, which every current Azure x64 size provides. Ask the system loader which levels your processor supports:

/lib64/ld-linux-x86-64.so.2 --help | grep -E 'x86-64-v[234]'

x86-64-v4 (supported, searched) x86-64-v3 (supported, searched) x86-64-v2 (supported, searched)

The top line depends on the processor behind your VM size. AlmaLinux 10 needs x86-64-v3 (supported, searched).

The reported version is the AlmaLinux 10 point release the image was patched to. This listing tracks the 10 major release, so dnf update rolls it forward across future point releases.

This layout is what sets the image apart. The root filesystem sits on an LVM logical volume inside a volume group, not on a fixed partition. The /boot and EFI system partitions stay as plain partitions, which is what the firmware and boot loader need:

df -hT / /boot /boot/efi

Filesystem Type Size Used Avail Use% Mounted on /dev/mapper/almalinux-root xfs 29G 1.5G 28G 6% / /dev/sda2 xfs 960M 244M 717M 26% /boot /dev/sda1 vfat 200M 9.1M 191M 5% /boot/efi

One physical volume, the third partition of the operating system disk, backs the volume group almalinux. The volume group holds a single logical volume, root. There is no swap volume:

sudo pvs
sudo vgs
sudo lvs -o lv_name,vg_name,lv_size,lv_path,devices

PV VG Fmt Attr PSize PFree /dev/sda3 almalinux lvm2 a-- 28.80g 0 VG #PV #LV #SN Attr VSize VFree almalinux 1 1 0 wz--n- 28.80g 0 LV VG LSize Path Devices root almalinux 28.80g /dev/almalinux/root /dev/sda3(0)

The kernel command line tells the early boot environment which logical volume holds the root filesystem. The LVM, partition-growing and XFS tools are all installed:

grep -o 'root=[^ ]*\|rd.lvm[^ ]*' /proc/cmdline rpm -q lvm2 cloud-utils-growpart xfsprogs

root=/dev/mapper/almalinux-root rd.lvm.lv=almalinux/root lvm2-2.03.36-2.el10.x86_64 cloud-utils-growpart-0.33-11.el10.noarch xfsprogs-6.16.0-1.el10.x86_64

The same rd.lvm.lv=almalinux/root argument is recorded in /etc/kernel/cmdline, so every kernel that a future update installs also boots from the logical volume.

Growing the root filesystem

The volume group ships with no free space, and enlarging the Azure disk does not grow the root volume on its own. cloud-init's automatic partition growth deliberately skips a root filesystem on a logical volume, so the extra capacity stays unallocated until you claim it.

First, enlarge the disk. Either create the machine with a larger disk (--os-disk-size-gb), or resize the disk in Azure: stop and deallocate the VM, raise the size, then start it again. Then run the block below. Every step works online, with no reboot, and the last lines confirm that the whole chain took effect:

sudo growpart /dev/sda 3
sudo pvresize /dev/sda3
sudo lvextend -l +100%FREE /dev/almalinux/root
sudo xfs_growfs / df -h /
FREE=$(sudo vgs --noheadings -o vg_free_count almalinux | tr -dc '0-9')
PVB=$(sudo pvs --noheadings --units b --nosuffix -o pv_size /dev/sda3 | tr -dc '0-9')
PARTB=$(( $(cat /sys/class/block/sda3/size) * 512 )) if [ "${FREE:-1}" -eq 0 ] && [ "$(( PARTB - PVB ))" -le 8388608 ]; then echo "root volume fully extended: 0 free extents in VG almalinux, and the physical volume fills the partition"; else echo "NOT fully extended: ${FREE:-?} free extents in VG almalinux, partition ${PARTB} B vs physical volume ${PVB:-?} B"; false; fi

Each command does one job:

• growpart extends partition 3 to the end of the disk.
• pvresize makes LVM see the larger physical volume.
• lvextend hands all the free space to the root logical volume.
• xfs_growfs grows the filesystem into it.

On a machine created with a 64 GB disk, the output looks like this:

CHANGED: partition=3 start=2508800 old: size=60403712 end=62912511 new: size=131708895 end=134217694 Physical volume "/dev/sda3" changed 1 physical volume(s) resized or updated / 0 physical volume(s) not resized Size of logical volume almalinux/root changed from 28.80 GiB (7373 extents) to 62.80 GiB (16077 extents). Logical volume almalinux/root successfully resized. meta-data=/dev/mapper/almalinux-root isize=512 agcount=4, agsize=1887488 blks ... data blocks changed from 7549952 to 16462848 Filesystem Size Used Avail Use% Mounted on /dev/mapper/almalinux-root 63G 2.2G 61G 4% / root volume fully extended: 0 free extents in VG almalinux, and the physical volume fills the partition

If the disk has not been enlarged, growpart prints NOCHANGE and lvextend reports that the size already matches. That is expected, and the final check still confirms that the volume fills the disk.

The two checks at the end catch the two ways a grow can silently stop short. Free extents left in the volume group mean lvextend did not run. A physical volume smaller than its partition means pvresize did not. Confirm the physical volume name with sudo pvs first. It is /dev/sda3 on this image.

Adding a data volume

Attach a new managed data disk in Azure. The portal and CLI show its LUN, and the matching device appears as /dev/disk/azure/data/by-lun/<N>. The older /dev/disk/azure/scsi1/lun<N> name works too. Give the disk its own volume group to keep application data separate from the operating system:

sudo pvcreate /dev/disk/azure/data/by-lun/0
sudo vgcreate datavg /dev/disk/azure/data/by-lun/0
sudo lvcreate -n datalv -l 100%FREE datavg
sudo mkfs.xfs /dev/datavg/datalv
sudo mkdir -p /data echo '/dev/datavg/datalv /data xfs defaults,nofail 0 0' | sudo tee -a /etc/fstab
sudo systemctl daemon-reload
sudo mount /data

The nofail option lets the machine still boot if the data disk is ever detached. To add the disk's capacity to the root volume instead, run sudo vgextend almalinux /dev/disk/azure/data/by-lun/0, then repeat the lvextend and xfs_growfs steps above.

The image ships /etc/lvm/devices empty, exactly like the standard AlmaLinux 10 Azure image. LVM therefore sees every attached disk, and a machine cloned from this image carries no record of the build machine's disks.

Every available update was applied when this image was built. Run dnf check-update, which exits 100 when updates are pending and 0 when none are:

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

exit=0

Nothing is waiting on a reboot either:

dnf needs-restarting -r

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

One kernel version is installed, the one the machine is running. Like the standard AlmaLinux 10 Azure image, it also carries the debug build of that same kernel. You can select the debug build from the boot menu when you diagnose a kernel problem. The machine boots the regular kernel by default:

rpm -q kernel-core kernel-debug-core
sudo grubby --default-kernel

kernel-core-6.12.0-211.53.1.el10_2.x86_64 kernel-debug-core-6.12.0-211.53.1.el10_2.x86_64 /boot/vmlinuz-6.12.0-211.53.1.el10_2.x86_64

Your update path is intact. BaseOS, AppStream, CRB (CodeReady Builder) and Extras are all enabled, which is the AlmaLinux 10 cloud image default. List them:

dnf repolist --enabled

repo id repo name appstream AlmaLinux 10 - AppStream baseos AlmaLinux 10 - BaseOS crb AlmaLinux 10 - CRB extras AlmaLinux 10 - Extras

Automatic updates

The standard AlmaLinux 10 Azure image does not include dnf-automatic. This image installs it and enables its timer, so the machine applies updates on its own schedule. Check the timer:

systemctl is-enabled dnf-automatic.timer

enabled

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

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

The policy applies all available updates, not only those tagged as security errata. It never reboots automatically, so a kernel update waits for a window you choose instead of restarting a production machine without warning:

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

upgrade_type = default download_updates = yes apply_updates = yes reboot = never

upgrade_type is deliberately default rather than security. A security-only policy depends on errata metadata being present for every update. Where the metadata is missing, it silently applies nothing, so default is the setting that actually keeps the machine current.

Because reboot = never, check periodically whether a restart is owed after a kernel update. Use the needs-restarting -r command above. To opt out of automatic updates entirely, run sudo systemctl disable --now dnf-automatic.timer.

Confirm SELinux is enforcing:

getenforce

Enforcing

Confirm the root account is locked. The L in the second field means locked:

sudo passwd -S root

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

Confirm no account on the machine has a usable password. This prints nothing on a clean image:

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

Read the SSH daemon's effective policy instead of the config file, because the running daemon is what a client actually meets:

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

permitrootlogin no pubkeyauthentication yes passwordauthentication no kbdinteractiveauthentication no

A drop-in file pins that policy. It sorts ahead of every other SSH configuration file, so a later package update to the main configuration cannot quietly loosen it:

sudo grep -vE '^#' /etc/ssh/sshd_config.d/00-sac-hardening.conf

PermitRootLogin no PasswordAuthentication no KbdInteractiveAuthentication no PermitEmptyPasswords no

There is no swap on the operating system disk and no swap logical volume, because swap baked into a Marketplace image is not permitted. This command prints nothing:

swapon --show

Confirm what is listening. SSH on port 22 is the only service reachable from the network. The only other socket is chronyd, bound to the loopback address for time synchronisation:

ss -tln
ss -uln

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 [::]:* 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 image ships nfs-utils for NFS version 4 client mounts, which need no extra listener. The rpcbind service that NFS version 3 relies on is installed but disabled, so port 111 stays closed:

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

disabled disabled

If you need NFS version 3, enable the service with sudo systemctl enable --now rpcbind.socket. Open only the ports you need in your Network Security Group.

The Azure Linux Agent handles extensions and the portal's recovery features. cloud-init provisions the machine. Check both:

systemctl is-active waagent rpm -q WALinuxAgent cloud-init chrony

active WALinuxAgent-2.14.0.1-3.el10.noarch cloud-init-24.4-7.el10_2.1.noarch chrony-4.8-2.el10.x86_64

cloud-init should report done, which means provisioning finished cleanly:

cloud-init status

status: done

The kernel puts a console on ttyS0. That console makes boot diagnostics and the portal's serial console work when you cannot reach the machine over SSH:

grep -o 'console=ttyS0' /proc/cmdline

console=ttyS0

Time synchronisation runs through chronyd against the Azure host clock (your offsets will differ):

chronyc -n sources | head -4

MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== #* PHC0 2 3 377 10 -58us[ -68us] +/- 11us

On sizes with a local temporary disk, such as Standard_B2s, cloud-init formats the disk and mounts it at /mnt. Treat anything on it as disposable, because Azure erases it whenever the machine is deallocated or moved:

findmnt -no SOURCE,FSTYPE,TARGET /mnt

/dev/sdb1 ext4 /mnt

The Azure Network Security Group controls inbound and outbound traffic. It is the first, and usually the only, place you need to open a port.

firewalld is not installed on this image:

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)

This matches the standard AlmaLinux 10 Azure image. With no host firewall in the way, your NSG rules take effect exactly as written, and there is no second layer to keep in sync. If your policy also requires a host firewall, install and enable it yourself:

sudo dnf install -y firewalld
sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --add-port=443/tcp sudo firewall-cmd --reload

Once firewalld is running, a port must be open in both the Azure NSG and firewalld before traffic can reach your service.

The AppStream repository carries the application packages. Check that a package such as nginx is available:

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

Available Packages nginx.x86_64 2:1.26.3-6.el10_2.6 appstream

Install a package and enable it in the usual way. For example, run sudo dnf install -y nginx, then sudo systemctl enable --now nginx, then open the port in your Network Security Group. Application data that grows, such as databases and web content, fits well on its own logical volume on a data disk (see Step 4).

To add another administrator, create the account with sudo adduser <name> and add it to the wheel group with sudo usermod -aG wheel <name>. Then copy your public key into /home/<name>/.ssh/authorized_keys. Set 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. List the members of that group with:

getent group wheel

Option A: AWS Marketplace console

• Open the SecureAnyCloud AlmaLinux listing on AWS Marketplace, choose View purchase options, then choose Subscribe. One subscription covers every version in the listing.
• When the subscription is active, choose Launch your software.
• Choose One-click launch from AWS Marketplace, or Launch from EC2 Console for full control. In Version, choose AlmaLinux 10 LVM - YYYY-MM-DD (the date is when the version was added), then select your Region.
• Instance type: m5.large is recommended, and any current x86_64 type works. The software charge is $0.04 per vCPU per hour.
• Key pair: choose your EC2 key pair. It is the only way in. RSA and ED25519 keys both work.
• Security group: allow inbound TCP 22 from your own IP address or network only.
• Storage: the root volume is 12 GiB gp3 by default. You can choose a larger size. The extra space stays unallocated in the LVM physical volume until you give it to the volumes you choose (Step 12).
• Metadata: leave the defaults, because the image already requires IMDSv2. Then choose Launch.

Option B: AWS CLI

Run this command on your own workstation. Replace the AMI ID with the one shown for your Region on the Marketplace launch page. Replace the key pair, security group and subnet with your own. The root device of this AMI is /dev/xvda:

aws ec2 run-instances \
  --image-id ami-0123456789abcdef0 \
  --instance-type m5.large \
  --key-name my-key-pair \
  --security-group-ids sg-0123456789abcdef0 \
  --subnet-id subnet-0123456789abcdef0 \
  --block-device-mappings 'DeviceName=/dev/xvda,Ebs={VolumeSize=20,VolumeType=gp3}' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=almalinux-10-lvm}]'

You do not need --metadata-options, because the AMI already requires IMDSv2.

From your workstation, connect as ec2-user with the key pair you chose:

ssh -i ~/.ssh/my-key-pair.pem ec2-user@<public-ip>

There is no password to enter. If SSH asks for one, or says Too many authentication failures, see Troubleshooting below.

You can also connect without opening port 22 at all, through AWS Systems Manager Session Manager. This requires an instance profile that allows Systems Manager. The agent is installed and running on this image.

cat /etc/almalinux-release grep -E '^(NAME|VERSION|ID|VERSION_ID|PLATFORM_ID|PRETTY_NAME)=' /etc/os-release uname -srm

Expected output:

AlmaLinux release 10.2 (Lavender Lion) NAME="AlmaLinux" VERSION="10.2 (Lavender Lion)" ID="almalinux" VERSION_ID="10.2" PLATFORM_ID="platform:el10" PRETTY_NAME="AlmaLinux 10.2 (Lavender Lion)" Linux 6.12.0-211.67.1.el10_2.x86_64 x86_64

This version follows AlmaLinux 10. It receives every AlmaLinux 10 minor release (10.2 at build time) through normal dnf updates. Your kernel version may be newer if updates have installed since the image was built.

List the disk and its volumes:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS /dev/nvme0n1

Expected output with the default 12 GiB root volume:

NAME SIZE TYPE FSTYPE MOUNTPOINTS nvme0n1 12G disk ├─nvme0n1p1 1M part ├─nvme0n1p2 200M part vfat /boot/efi ├─nvme0n1p3 1G part xfs /boot └─nvme0n1p4 10.8G part LVM2_member ├─almalinux-root 4G lvm xfs / ├─almalinux-home 1G lvm xfs /home ├─almalinux-tmp 1G lvm xfs /tmp ├─almalinux-var 1.5G lvm xfs /var ├─almalinux-var_tmp 512M lvm xfs /var/tmp ├─almalinux-var_log 1G lvm xfs /var/log └─almalinux-var_log_audit 1G lvm xfs /var/log/audit

Show the volume group, its logical volumes and the mount options each volume carries:

sudo vgs
sudo lvs -o lv_name,lv_size,lv_path almalinux for m in / /home /tmp /var /var/tmp /var/log /var/log/audit /boot /dev/shm; do printf '%-15s %-36s %s\n' "$m" "$(findmnt -no SOURCE "$m")" "$(findmnt -no OPTIONS "$m" | tr , '\n' | grep -xE 'rw|ro|nodev|nosuid|noexec' | paste -sd, -)"; done

Expected output:

VG #PV #LV #SN Attr VSize VFree almalinux 1 7 0 wz--n- 10.80g 820.00m LV LSize Path home 1.00g /dev/almalinux/home root 4.00g /dev/almalinux/root tmp 1.00g /dev/almalinux/tmp var 1.50g /dev/almalinux/var var_log 1.00g /dev/almalinux/var_log var_log_audit 1.00g /dev/almalinux/var_log_audit var_tmp 512.00m /dev/almalinux/var_tmp / /dev/mapper/almalinux-root rw /home /dev/mapper/almalinux-home rw,nosuid,nodev /tmp /dev/mapper/almalinux-tmp rw,nosuid,nodev,noexec /var /dev/mapper/almalinux-var rw,nosuid,nodev /var/tmp /dev/mapper/almalinux-var_tmp rw,nosuid,nodev,noexec /var/log /dev/mapper/almalinux-var_log rw,nosuid,nodev,noexec /var/log/audit /dev/mapper/almalinux-var_log_audit rw,nosuid,nodev,noexec /boot /dev/nvme0n1p3 rw,nosuid,nodev /dev/shm tmpfs rw,nosuid,nodev,noexec

• The disk has a 1 MiB BIOS boot partition, a 200 MiB EFI system partition, a 1 GiB /boot (XFS) and one LVM physical volume. The instance boots in UEFI mode where the instance type supports it, and in legacy BIOS mode otherwise.
• The mount options are set in /etc/fstab by filesystem UUID, so they survive reboots and apply on every instance launched from the image. The last column shows the options that matter for the benchmark. findmnt lists the rest.
• The volume group keeps 820 MiB free at the default size, so you can grow the volume that fills first without touching EBS (Step 12).

The kernel finds its root filesystem on the logical volume. The same arguments are recorded in /etc/kernel/cmdline, so every kernel that a future update installs also boots from the logical volume:

grep -o 'root=[^ ]*\|rd.lvm[^ ]*' /proc/cmdline
grep -o 'root=[^ ]*\|rd.lvm[^ ]*' /etc/kernel/cmdline rpm -q lvm2 cloud-utils-growpart xfsprogs

Expected output:

root=/dev/mapper/almalinux-root rd.lvm.lv=almalinux/root root=/dev/mapper/almalinux-root rd.lvm.lv=almalinux/root lvm2-2.03.36-2.el10.x86_64 cloud-utils-growpart-0.33-11.el10.noarch xfsprogs-6.16.0-1.el10.x86_64

The evaluation that the build ran after its reboot ships on the image. Read the files and the summary:

ls -lh /usr/share/doc/sac/ python3 -c "import json; s=json.load(open('/usr/share/doc/sac/cis-l1-summary.json')); print('profile: ', s['profileLabel'], '(SCAP Security Guide', s['ssgVersion'] + ')'); print('scored rules: ', s['scored'], ' pass:', s['pass'], ' fail:', s['fail'], ' rate:', str(s['ratePct']) + '%'); print('waived: ', s['waived'], ' not applicable:', s['notapplicable']); print('evaluated at: ', s['evaluatedAt'])"

Expected output:

total 32M -rw-r--r--. 1 root root 29M Oct 19 14:57 cis-l1-arf.xml -rw-r--r--. 1 root root 2.5M Oct 19 14:57 cis-l1-report.html -rw-r--r--. 1 root root 1.2K Oct 19 14:57 cis-l1-summary.json -rw-r--r--. 1 root root 1.7K Oct 19 14:57 cis-l1-tailoring.xml -rw-r--r--. 1 root root 2.6K Oct 19 14:57 cis-l1-waivers.txt -rw-r--r--. 1 root root 1.6K Oct 19 14:53 scap-security-guide-LICENSE.txt profile: CIS Level 1 Server (SCAP Security Guide 0.1.82) scored rules: 303 pass: 302 fail: 1 rate: 99.7% waived: 6 not applicable: 15 evaluated at: 2026-10-19T14:57:20Z

• cis-l1-report.html is the full OpenSCAP report, rule by rule. Copy it to your workstation and open it in a browser.
• cis-l1-arf.xml is the same evaluation in the machine-readable ARF format, for compliance tooling.
• cis-l1-tailoring.xml is the exact tailoring used, so you can re-run the same evaluation (Step 6).
• The pass rate is pass / (pass + fail + error + unknown). Rules that are not applicable to this machine, not selected, or waived are not counted.
• Compared with the single-volume versions of this listing, the partition rules are scored here and pass. These cover /tmp, /var, /var/tmp, /var/log, /var/log/audit and /home on their own partitions, and their mount options.

To copy the report to your workstation, run this command on the workstation:

scp -i ~/.ssh/my-key-pair.pem ec2-user@<public-ip>:/usr/share/doc/sac/cis-l1-report.html .

The six waived rules

List the waived rules and their groups:

grep -v '^#' /usr/share/doc/sac/cis-l1-waivers.txt | cut -f1,2

Expected output:

grub2_password [serial-console-and-boot] ensure_root_password_configured [serial-console-and-boot] accounts_maximum_age_login_defs [key-only-account-aging] account_disable_post_pw_expiration [key-only-account-aging] sshd_limit_user_access [ssh-access-list] service_systemd-journal-upload_enabled [log-remote-destination]

The third column of the same file gives the full reason for each. In short:

• Boot loader and root passwords: a GRUB or root password would have to be baked into the image, giving every instance the same secret. Root stays locked with no password. Set your own if you need serial console access (see Step 11).
• Password ageing defaults: the accounts cloud-init creates are key-only. An ageing limit would expire them and lock the SSH key out. Accounts that do have a password are still aged.
• SSH AllowUsers/AllowGroups: a list fixed at build time would refuse accounts you create later. Your security group restricts who can reach port 22.
• Journal upload to a remote log server: the profile switches on systemd-journal-upload but sets no destination, and an image cannot know your log server. With no destination, the service fails at every boot. systemd-journal-remote is installed and the upload service is left off. To enable it, put URL= for your collector in /etc/systemd/journal-upload.conf, then run sudo systemctl enable --now systemd-journal-upload.

The one rule that does not pass

Print the failing rule:

python3 -c "import json; [print(r) for r in json.load(open('/usr/share/doc/sac/cis-l1-summary.json'))['failingRules']]"

Expected output:

ensure_journald_and_rsyslog_not_active_together

The benchmark wants one logging system, not both. AlmaLinux runs journald and rsyslog together by default. journald keeps the structured system journal (persistent, in /var/log/journal). rsyslog writes the traditional text logs (/var/log/messages, /var/log/secure, /var/log/cron) that many log shippers and audit procedures read.

The image keeps both so that neither kind of tooling loses its logs. If you standardise on one, for example the journal only, run sudo systemctl disable --now rsyslog on your instance and re-run Step 6.

Repeat the evaluation at any time with the same content and tailoring. It takes about a minute:

sudo oscap xccdf eval \
  --tailoring-file /usr/share/doc/sac/cis-l1-tailoring.xml \
  --profile xccdf_co.sac_profile_cis-l1_ec2_lvm \
  --results /tmp/cis-check-results.xml --report /tmp/cis-check-report.html \
  /usr/share/xml/scap/ssg/content/ssg-almalinux10-ds.xml > /tmp/cis-check.log 2>&1 echo "oscap exit code: $? (2 = at least one rule did not pass)"
sudo python3 -c "import re,collections; c=collections.Counter(re.findall(r'<result>(\w+)</result>', open('/tmp/cis-check-results.xml').read())); s=sum(c[k] for k in ('pass','fail','error','unknown')); print(dict(sorted(c.items()))); print('pass rate: %.1f%%' % (100.0*c['pass']/s))"

Expected output:

oscap exit code: 2 (2 = at least one rule did not pass) {'fail': 1, 'notapplicable': 15, 'notselected': 755, 'pass': 302} pass rate: 99.7%

Your own report is at /tmp/cis-check-report.html. As you install software and change settings, re-run the evaluation to see how your changes affect the result.

/tmp is noexec, which does not affect oscap. It runs its remediation and check scripts through their interpreter.

Request instance metadata without a token, then with one:

curl -s -o /dev/null -w 'IMDSv1 request without a token: HTTP %{http_code}\n' http://169.254.169.254/latest/meta-data/instance-id
TOKEN=$(curl -s -X PUT -H 'X-aws-ec2-metadata-token-ttl-seconds: 60' http://169.254.169.254/latest/api/token)
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" -w '\n' http://169.254.169.254/latest/meta-data/placement/region

Expected output (your Region may differ):

IMDSv1 request without a token: HTTP 401 us-east-1

A request without a session token is refused with HTTP 401, and the same request with a token works. Scripts and SDKs on the instance must use IMDSv2. Every current AWS SDK and the AWS CLI do this automatically.

Check the firewall state and the listening sockets:

sudo firewall-cmd --state sudo firewall-cmd --list-all sudo ss -tlnp

Expected output:

running public (default, active) target: default ingress-priority: 0 egress-priority: 0 icmp-block-inversion: no interfaces: eth0 sources: services: dhcpv6-client ssh ports: protocols: forward: yes masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1463,fd=7)) LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=1463,fd=8))

• Only sshd listens, on port 22. Nothing else on the image opens a TCP port.
• The public zone allows ssh and dhcpv6-client. The DHCPv6 client receives replies for the instance's IPv6 DHCP client, which is how an instance in an IPv6-enabled subnet gets its address. The AlmaLinux default cockpit service is removed from the zone, and Cockpit is not installed.
• The loopback interface sits in firewalld's trusted zone. Rules drop any traffic that claims a loopback source from anywhere else (a CIS requirement).

Opening a port for your own service takes two steps. Allow the port in the instance's security group, and allow it in firewalld. For example, for a web server on 443, run this on the instance:

sudo firewall-cmd --permanent --add-service=https sudo firewall-cmd --reload

If a port is open in the security group but not in firewalld, or the other way round, the traffic does not arrive.

Check both services and the time sources:

systemctl is-active chronyd amazon-ssm-agent chronyc -n sources

Expected output (the pool servers and timings vary):

active active MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^- 5.254.77.191 2 6 37 59 -361us[ -362us] +/- 2278us ^- 149.248.12.167 3 6 37 59 +2258us[+2257us] +/- 29ms ^- 72.14.183.239 3 6 37 59 -1899us[-1900us] +/- 83ms ^- 137.190.2.4 1 6 37 58 +749us[ +748us] +/- 25ms ^* 169.254.169.123 3 4 377 11 -3808ns[-5258ns] +/- 489us

The ^* marks the source chrony is using: 169.254.169.123, the Amazon Time Sync Service. It is reachable from every instance without internet access, so time stays correct in a private subnet too. The public AlmaLinux pool servers are fallbacks.

The AWS Systems Manager agent is installed from Amazon's own package at its current release (3.3.5390.0 on this build). It is not in the AlmaLinux repositories, so dnf does not update it. Systems Manager can keep it current for you, through the AWS-UpdateSSMAgent document or the Auto update SSM Agent setting in Fleet Manager.

The image is fully patched at build time. Check what is pending now:

sudo dnf -q check-update --refresh echo "dnf check-update exit code: $? (0 = nothing to update, 100 = updates available)" grep -E '^(upgrade_type|apply_updates)' /etc/dnf/automatic.conf systemctl is-enabled dnf-automatic.timer uname -r

Expected output on an instance launched soon after the image was built (later launches list the updates released since, with exit code 100):

dnf check-update exit code: 0 (0 = nothing to update, 100 = updates available) upgrade_type = security apply_updates = yes enabled 6.12.0-211.67.1.el10_2.x86_64

dnf-automatic runs daily (06:00, with a random delay of up to an hour) and installs security updates automatically. To update everything immediately, run:

sudo dnf -y upgrade

Reboot if a new kernel was installed:

sudo systemctl reboot

A new kernel boots from the logical volume like the current one, because its boot entry is built from /etc/kernel/cmdline (Step 4).

Check SELinux, the root account and the effective SSH policy:

getenforce
sudo passwd -S root
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication|maxauthtries|clientaliveinterval|banner) ' cat /etc/issue.net

Expected output:

Enforcing root L 2024-12-14 0 99999 7 -1 maxauthtries 4 clientaliveinterval 300 permitrootlogin no pubkeyauthentication yes passwordauthentication no banner /etc/issue.net Authorized users only. All activity may be monitored and reported.

• Enforcing means SELinux is on and enforcing the targeted policy. Keep it on. If your own software is denied, check sudo ausearch -m avc -ts recent instead of disabling SELinux.
• L in the second column means the root account is locked.
• maxauthtries 4 and clientaliveinterval 300 come from the CIS profile. SSH allows four authentication attempts per connection and checks idle sessions every five minutes.
• The banner text is shown before login.

EC2 Serial Console and recovery. No account on this image has a password, so the serial console cannot log in until you set one. If you want serial console access, set a password for your own user on your running instance. The password is yours and is not on the image:

sudo passwd ec2-user

Check the volume group, the first-boot partition growth, swap and the AIDE schedule:

sudo vgs almalinux df -h / /var /var/log
sudo grep -E 'cc_growpart.py.*(SKIPPED|resized|NOCHANGE)' /var/log/cloud-init.log | tail -1 | cut -c1-150 swapon --noheadings --show | wc -l sudo grep -h aide /etc/crontab

Expected output with the default 12 GiB root volume:

VG #PV #LV #SN Attr VSize VFree almalinux 1 7 0 wz--n- 10.80g 820.00m Filesystem Size Used Avail Use% Mounted on /dev/mapper/almalinux-root 4.0G 1.3G 2.7G 33% / /dev/mapper/almalinux-var 1.5G 182M 1.3G 13% /var /dev/mapper/almalinux-var_log 960M 52M 909M 6% /var/log 2026-10-19 15:38:18,278 - cc_growpart.py[DEBUG]: '/' SKIPPED: Resizing mapped device (/dev/mapper/almalinux-root) skipped as it is not encrypted. 0 05 4 * * * root /usr/sbin/aide --check

cloud-init does not grow LVM volumes. On a single-volume AlmaLinux image, cloud-init grows the root filesystem to the volume size on first boot. On this image the root filesystem is a logical volume, so cloud-init skips it (the SKIPPED line above). This is deliberate: you decide which volume gets the space.

Launch with a bigger root volume, or grow the EBS volume later with aws ec2 modify-volume. Then add the space in three steps on the instance:

1. Grow partition 4 (the LVM physical volume) to the end of the disk, and tell LVM:

sudo growpart /dev/nvme0n1 4
sudo pvresize /dev/nvme0n1p4

2. Give space to the volumes that need it. --resizefs grows the XFS filesystem in the same step, online, with no reboot:

sudo lvextend --resizefs -L +4G /dev/almalinux/root
sudo lvextend --resizefs -L +2G /dev/almalinux/var

3. Check the result:

sudo vgs almalinux df -h / /var

Example output after growing a 12 GiB volume to 20 GiB and running the commands above (the filesystem geometry that xfs_growfs prints is shortened to ...):

CHANGED: partition=4 start=2510848 old: size=22652928 end=25163775 new: size=39432159 end=41943006 Physical volume "/dev/nvme0n1p4" changed 1 physical volume(s) resized or updated / 0 physical volume(s) not resized File system xfs found on almalinux/root mounted at /. Size of logical volume almalinux/root changed from 4.00 GiB (1024 extents) to 8.00 GiB (2048 extents). Extending file system xfs to 8.00 GiB (8589934592 bytes) on almalinux/root... xfs_growfs /dev/almalinux/root ... data blocks changed from 1048576 to 2097152 xfs_growfs done Extended file system xfs on almalinux/root. Logical volume almalinux/root successfully resized. File system xfs found on almalinux/var mounted at /var. Size of logical volume almalinux/var changed from 1.50 GiB (384 extents) to 3.50 GiB (896 extents). Extending file system xfs to 3.50 GiB (3758096384 bytes) on almalinux/var... xfs_growfs /dev/almalinux/var ... data blocks changed from 393216 to 917504 xfs_growfs done Extended file system xfs on almalinux/var. Logical volume almalinux/var successfully resized. VG #PV #LV #SN Attr VSize VFree almalinux 1 7 0 wz--n- 18.80g 2.80g Filesystem Size Used Avail Use% Mounted on /dev/mapper/almalinux-root 8.0G 1.4G 6.6G 17% / /dev/mapper/almalinux-var 3.5G 221M 3.3G 7% /var

To give a volume all the remaining free space instead, use -l +100%FREE, for example sudo lvextend --resizefs -l +100%FREE /dev/almalinux/var_log. Leaving some space unallocated is useful, because you can then grow whichever volume fills first without touching EBS. XFS volumes grow online but cannot shrink, so add space in steps.

• Adding a data volume. Attach a new EBS volume, then give it its own volume group (for example sudo pvcreate /dev/nvme1n1, sudo vgcreate datavg /dev/nvme1n1, sudo lvcreate -n data -l 100%FREE datavg, sudo mkfs.xfs /dev/datavg/data). Mount it from /etc/fstab by UUID with the nofail option, so the instance still boots if the volume is ever detached. Check the device name with lsblk first. On Nitro instances the second EBS volume is usually /dev/nvme1n1. The image ships no LVM devices file (/etc/lvm/devices/system.devices), so LVM sees every attached disk.
• Swap. The image has no swap. If your workload needs it, create a logical volume for it (for example sudo lvcreate -L 2G -n swap almalinux, then sudo mkswap /dev/almalinux/swap and an /etc/fstab entry), or use a swap file on / or /var.
• AIDE. The file integrity database is built from the image's own files, and the CIS profile schedules aide --check daily at 04:05 from /etc/crontab.

The instance uses the standard AlmaLinux 10 repositories (BaseOS, AppStream, CRB and Extras). Check that a package such as nginx is available:

sudo dnf -q list --available nginx

Expected output (the version changes over time):

Available Packages nginx.x86_64 2:1.26.3-6.el10_2.7 appstream

Install and start software in the usual way. For example, run sudo dnf -y install nginx, then sudo systemctl enable --now nginx. Open its port in the security group and firewalld (Step 8).

Most software installs under /usr and /etc on the root volume and keeps its data and logs under /var. Watch the / and /var volumes as you add software, and grow them as needed (Step 12). The AWS CLI is not on the image. Install the current version from AWS (the AWS CLI install guide) if you need it.

To add another administrator, create the account, add it to the wheel group and give it an SSH key:

sudo useradd -m -G wheel alice
sudo install -d -m 700 -o alice -g alice /home/alice/.ssh echo "ssh-ed25519 AAAA... alice@laptop" | sudo tee /home/alice/.ssh/authorized_keys
sudo chown alice:alice /home/alice/.ssh/authorized_keys && sudo chmod 600 /home/alice/.ssh/authorized_keys
sudo restorecon -R /home/alice/.ssh

Because SSH is key-only, a new account needs its key in authorized_keys. The restorecon command gives the file the SELinux label that sshd expects.

The new account has no password, so sudo cannot authenticate it until you give it one with sudo passwd alice. SSH stays key-only, and sudo uses the password. Only ec2-user, created by cloud-init, has password-free sudo.