AlmaLinux 10 Minimal

Option A: AWS Marketplace console

• Open the SecureAnyCloud AlmaLinux listing on AWS Marketplace. Choose View purchase options, then 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 Minimal - YYYY-MM-DD (the date is when the version was added), then choose your Region.
• Choose an instance type. m5.large is recommended, and any current x86_64 type works. The software charge is $0.04 per vCPU per hour.
• Choose your EC2 key pair. It is the only way in. RSA and ED25519 keys both work.
• Configure the security group to allow inbound TCP 22 from your own IP address or network only.
• Set the storage. The root volume is 10 GiB gp3 by default. Choose a larger size if you need one. cloud-init grows the root partition and filesystem to fill it on first boot.
• Leave the metadata 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/sda1:

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/sda1,Ebs={VolumeSize=20,VolumeType=gp3}' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=almalinux-10-minimal}]'

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 reports Too many authentication failures, see Troubleshooting below.

You can also connect without opening port 22 through AWS Systems Manager Session Manager, if the instance has 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 this image was built.

The image lists exactly what was removed. If a removal would have taken another needed package with it, that package is kept and listed instead:

cat /usr/share/doc/sac/minimal-manifest.txt rpm -qa | wc -l

Expected output:

Minimal version: packages 412 -> 404 Removed: tuned sos Kept (a removal would have taken a protected package, or it failed): 416

The trim takes the package count from 412 to 404, including the dependencies that left with those two packages. Nothing had to be kept back. The base image is already small, so most of the candidate list (wireless and sound firmware, Cockpit, Plymouth) was never installed.

After the trim, the CIS remediation adds the tools it needs (OpenSCAP, AIDE, the journal upload client and their libraries), and the build removes the superseded kernels. This is why a new instance has 416 packages. The count on your instance changes by a few as kernels and updates install.

Anything removed is one sudo dnf install away from the standard AlmaLinux repositories.

The evaluation that the build ran after its reboot ships on the image. List the files:

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 23:36 cis-l1-arf.xml -rw-r--r--. 1 root root 2.4M Oct 19 23:36 cis-l1-report.html -rw-r--r--. 1 root root 1.3K Oct 19 23:36 cis-l1-summary.json -rw-r--r--. 1 root root 1.9K Oct 19 23:36 cis-l1-tailoring.xml -rw-r--r--. 1 root root 2.9K Oct 19 23:36 cis-l1-waivers.txt -rw-r--r--. 1 root root 129 Oct 19 23:33 minimal-manifest.txt -rw-r--r--. 1 root root 1.6K Oct 19 23:33 scap-security-guide-LICENSE.txt profile: CIS Level 1 Server (SCAP Security Guide 0.1.82) scored rules: 286 pass: 285 fail: 1 rate: 99.7% waived: 7 not applicable: 31 evaluated at: 2026-10-19T23:36:49Z

• 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.

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 seven waived rules

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

Expected output:

partition_for_tmp [single-volume-partitions] 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 full reason for each rule is in the third column of the same file. In short:

• Separate /tmp partition. This version boots from one EBS root volume. The LVM versions of this listing provide separate volumes for /tmp, /var, /var/log, /var/log/audit, /var/tmp and /home.
• Boot loader and root passwords. A GRUB or root password would have to be baked into the image, which would give every instance the same secret. Root stays locked with no password. Set your own if you need serial console access (see Step 11).
• Password aging defaults. The accounts that cloud-init creates are key-only. An aging 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 that 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

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 neither kind of tooling loses its logs. If you standardize on one, for example the journal only, run sudo systemctl disable --now rsyslog on your instance and re-run Step 6.

You can repeat the evaluation at any time with the same content and tailoring. It takes under a minute. Run it:

sudo oscap xccdf eval \
  --tailoring-file /usr/share/doc/sac/cis-l1-tailoring.xml \
  --profile xccdf_co.sac_profile_cis-l1_ec2_single \
  --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': 31, 'notselected': 756, 'pass': 285} 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.

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.

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=1070,fd=7)) LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=1070,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, which carries replies to the instance's IPv6 DHCP client. This 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 the firewalld trusted zone, with rules that drop traffic claiming a loopback source from anywhere else (a CIS requirement).

To open a port for your own service, allow it in two places: the instance's security group and 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.

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 =============================================================================== ^- 23.186.168.125 2 6 17 45 -977us[ -186us] +/- 55ms ^- 216.66.48.42 1 6 17 45 +1876us[+2667us] +/- 9570us ^- 108.61.56.35 2 6 17 45 -453us[ +338us] +/- 50ms ^- 69.10.208.170 2 6 17 45 -586us[ +205us] +/- 67ms ^* 169.254.169.123 3 4 77 13 +12us[ +379us] +/- 644us

The ^* marks the source that 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, using the AWS-UpdateSSMAgent document or the Auto update SSM Agent setting in Fleet Manager.

The image is fully patched at build time. Check which updates are 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 now, run:

sudo dnf -y upgrade

Reboot if a new kernel was installed:

sudo systemctl reboot

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 rather than 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

df -hT /
sudo grep -E 'cc_growpart.*(resized|NOCHANGE)' /var/log/cloud-init.log | tail -1 swapon --noheadings --show | wc -l sudo grep -h aide /etc/crontab

Expected output with the default 10 GiB root volume (on a larger volume, Size is larger and the cloud-init line says resized):

Filesystem Type Size Used Avail Use% Mounted on /dev/nvme0n1p4 xfs 8.8G 1.5G 7.4G 17% / 2026-10-19 23:58:17,083 - cc_growpart.py[DEBUG]: '/' NOCHANGE: no change necessary (/dev/nvme0n1, 4) 0 05 4 * * * root /usr/sbin/aide --check

• Disk layout. The instance boots with UEFI. The root filesystem is XFS on partition 4 of the root volume. /boot (XFS) and /boot/efi are separate small partitions.
• Disk growth. cloud-init grows the root partition and filesystem to the volume size on first boot. To grow the volume later, increase the EBS volume size in the console or with aws ec2 modify-volume. Then run sudo growpart /dev/nvme0n1 4 && sudo xfs_growfs /, or reboot.
• Swap. The image has no swap. Add a swap file yourself if your workload needs one.
• 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):

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 sudo dnf -y install nginx then sudo systemctl enable --now nginx. Open its port in the security group and firewalld (Step 8). The AWS CLI is not on the image. If you need it, install the current version from AWS (see the AWS CLI install guide).

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.