This solution does not protect you if an attacker has physical access to the server and can re-connect the hard disk (or disk image) to another running system. But it's not bad if you just want to disable editing of grub boot options for unauthorized operators who however have access to the boot process (for example, to the VM console).
Create /boot/grub2/custom.cfg with the following content:
# List of users with superuser rights: set superusers="manager" export superusers # Define another user "user": password user Abcd1234 # Set encrypted pass for user "manager": password_pbkdf2 manager grub.pbkdf2.sha512.10000....Very.Long.Hexadecimal.Line
How to get this Very.Long.Hexadecimal.Line ? Use grub2-mkpasswd-pbkdf2:
# grub2-mkpasswd-pbkdf2 Enter password: Reenter password: PBKDF2 hash of your password is grub.pbkdf2.sha512.10000....Very.Long.Hexadecimal.Line
Once you've set this file, the grub will ask for user and password at boot time. This is not usefull for server farm, because every reboot require you open console and enter password. Reboot and check this (will not ask for password for some distros, Fedora 25 for example).
As a solution, --unrestricted option should be added to default menuentry. Then default boot will continue boot without requesting password. GRUB will ask you for this password, however, if you need to change boot parameters in it (like boot into single user mode). Fedora adds this option in template file to fix this for every menuentry even newly added after kernel update:
# grep unrestricte /etc/grub.d/* /etc/grub.d/10_linux:CLASS="--class gnu-linux --class gnu --class os --unrestricted"
Another fine grained option for menuentry is --users, that allow particular user access to this entry too. I see this option as useless, therefore there is no example for that.