虚拟机引导加密的通用做法是“双重加密”：宿主机磁盘层用LUKS兜底，虚拟机系统盘再用BitLocker或LUKS二次加密，启动时通过虚拟TPM自动解锁或手动输口令，这样即便宿主机被拖走，虚拟磁盘文件只是一堆密文。
虚拟机引导加密怎么做？先分清三个层面
很多同学把“虚拟机加密”当成一个操作，实际上它至少横跨三个层面。每个层面防的威胁不一样，选择路径也不同。
KVM场景：宿主机LUKS加密，虚拟机跟着受益
如果你用的是KVM/QEMU，最硬核的玩法是给宿主机磁盘整块上LUKS，安装Ubuntu Server或Debian时手动分区，选加密逻辑卷，之后KVM虚拟机镜像文件落在加密块设备上，这台宿主机每次重启，都要先输入LUKS口令解锁宿主机磁盘,然后虚拟机才能被启动。
这套方案的优势在于对虚拟机内部完全透明，虚拟机不知道宿主机底层发生了什么，镜像文件在磁盘上永远是密文状态，好处是配置简单，坏处是宿主机一旦开机,所有虚拟机镜像都会暴露给任何拿到系统权限的人。
虚拟机内部再来一层LUKS或BitLocker
真正意义上的“虚拟机引导加密”，指的是在客户机操作系统层面做的加密，Windows虚拟机里开BitLocker，Linux虚拟机里对根分区做LUKS，这样防的是镜像文件被别人拷走，比如从ESXi数据存储里直接把vmdk下载出来,没有密钥就解不开。
这个层面还有细分的玩法：可以用cryptsetup luksFormat处理根分区，配合系统安装器完成引导，Windows则更容易，直接在系统属性里启用BitLocker，注意虚拟机得先挂载虚拟TPM设备,否则BitLocker只能走密码解锁模式。
平台级加密：VMware加密虚拟机是另一条路
VMware的vSphere提供原生的“加密虚拟机”功能，不需要进客户机内部配BitLocker，运维人员只需给虚拟机打上加密策略，虚拟磁盘就会在数据存储层面自动落盘加密，依赖KMS（密钥管理服务器）保存密钥,对虚拟机内部也是透明加密。
Hyper-V这边则靠BitLocker的脱机加密，或者直接在宿主机启用Storage Spaces加密。规划时想清楚自己防的是“镜像被拷走”还是“宿主机被入侵”，这两个目标决定路径差很多。
系统启动时如何安全验证密钥？从头到尾不让密钥落盘
密钥验证的安全底线是：
密码、密钥文件不能以明文出现在虚拟机的虚拟磁盘里。 系统启动时，引导程序需要拿到密钥来解锁磁盘,但解锁完就要忘记这把钥匙。
虚拟TPM负责“悄悄”解锁
KVM和VMware都支持虚拟TPM（vTPM）设备，Windows虚拟机开着BitLocker时，启动阶段引导程序会向vTPM芯片要一个密封好的密钥，虚拟TPM验证固件状态和引导加载程序哈希值之后，才把密钥吐出来，这个过程中没有人工干预，运维人员远程重启虚拟机也能自动启动,体验很好。
VMware Workstation在虚拟机设置里加一个“可信平台模块”即可,KVM环境则需要在虚拟机XML中挂载虚拟TPM设备：
<tpm model='tpm-crb'> <backend type='emulator' version='2.0'/> </tpm>
挂在之后启动虚拟机，进入系统后能检查到标准TPM 2.0设备，Windows BitLocker自动识别，Linux的systemd-cryptenroll也能和它配合。
没有TPM时只能靠交互式密码
多数老虚拟机或混合虚拟化环境不具备vTPM，引导时只能老实输入密码，Linux LUKS的做法是先在宿主机上启动虚拟机，然后KVM窗口里出现initramfs的解锁界面，输入口令之后继续加载系统，这条路的问题是没有人工盯着，自动重启就卡在密码界面,所以很多机房场景并不推荐单独依赖这种模式。
密钥签入要靠一次性“握手”
安全验证密钥还有一个关键动作：密钥传递，业内专家指出，vTPM在虚拟化环境中的可用性更依赖虚拟化层创建的信任根，它验证的是引导链上的各个组件哈希值，真正要确保密钥不泄露，得在首次配置时确保密钥只在内存中完成交换，然后密封进vTPM的防篡改存储区,磁盘上不落任何明文副本。
实操：KVM虚拟机全盘加密从装到开机自动解锁
下面是一套相对靠谱的深水区操作，目标：KVM虚拟机做成LUKS加密盘，启动时利用密钥文件在initramfs阶段自动解锁,不需要人工介入。
第一步：给宿主机分区上锁
先把宿主机建好LUKS加密分区，使用系统安装器自带的“加密整个系统”是最快的路径，分区格式化为LUKS2,挂载进LVM。
第二步：虚拟机内创建LUKS分区
虚拟机安装系统时手动分区,把根分区设为加密卷：
cryptsetup luksFormat /dev/vda2 cryptsetup open /dev/vda2 cryptroot
后续安装流程照常,把cryptroot作为根分区挂载。
第三步：配置启动时自动解锁
要让系统启动时不用手工输密码，需要用密钥文件替代输入密码，把密钥文件放到initramfs里面,或者直接在cryptab里指定：
echo "cryptroot UUID=your-partition-uuid /etc/luks-keys/root.key luks" >> /etc/crypttab
然后重建initramfs让密钥文件被封装进去：
update-initramfs -u
需要注意，/boot分区不能被加密在根分区内部，否则引导加载器根本没机会加载initramfs，把/boot独立建一个未加密小分区,是这类场景的行业共识做法。
第四步：验证整个链路
重启虚拟机，系统应该自动通过密钥文件解锁cryptroot，最后直接进入登录界面。验证时故意手动敲错密钥路径，确认系统会掉进救援壳而不是默默跳过加密。
VMware场景的启动验证与常见坑
VMware的虚拟机和KVM差别不小,尤其是vTPM的绑定关系可能直接影响启动验证。
VMware虚拟机无法自动解锁的两种尴尬局面
第一种是克隆虚拟机后忘记清除原机vTPM信息，BitLocker会比较系统磁盘状态和vTPM密封状态，克隆出来的虚拟机会因为系统盘序列号、引导配置有变化直接被拒绝自动解锁,停在那里等恢复密钥。
第二种是跨ESXi主机迁移之后出现“虚拟机加密密钥不可用”，如果目标集群没配置同样的KMS，或者vTPM没跟着迁移过去，启动时系统会报密钥丢失，这种问题的解法是在关闭虚拟机的状态下先备份并移除原vTPM，再添加新vTPM,然后用BitLocker恢复密钥进入系统重新加密。
VMware Workstation和ESXi场景不一样
本地用VMware Workstation跑加密虚拟机，密码敲错后会卡在BitLocker恢复界面反复打转，这种情况下，要么采用TPM+PIN码组合，要么保留一个恢复密钥导出到宿主机本地文件，国内机房托管场景下，多数团队会额外把恢复密钥打印存放在物理安全柜里，不放在服务器同一机房,防止物理入侵后顺手拿密。
虚拟机加密后的救急问题与性能权衡
很多人装完加密虚拟机第一次重启后，就再也进不了系统，这里面最大的坑是启动链路中
cryptab配置阶段就出错，系统根本找不到真正的根分区,排查思路很简单：
- 检查
cryptab中的UUID是否准确，用blkid比对。 - 检查initramfs是否包含
/etc/luks-keys/下的密钥文件。 - 检查
/etc/fstab是否引用了未解锁的/dev/mapper/cryptroot设备。
密码或密钥都有效的情况下，可以尝试从宿主机上用virt-customize挂载虚拟机磁盘，直接修改cryptab，这个工具比 guestmount 更省事,而且不需要解锁LUKS里面的内容。
性能方面，多数情况下虚拟机加解密会在几十到几百MB/s的吞吐量区间内可感知下降，但具体损耗取决于虚拟化层能否透传硬件AES指令，近年发布的物理服务器基本都支持，如果是老旧CPU或者嵌套虚拟化运行虚拟机，加密吞吐会明显下降。
虚拟机引导加密最怕的是忘记密钥，这比丢失数据更难受，建议在多用户协作维护虚拟化平台时，单独配置一份密钥备份流程，将密钥文件用GPG加密后存储在内部密钥管理平台上，定期验证备份能成功解锁,而不是等到机房断电重启所有人面面相觑。
Q&A：虚拟机引导加密与密钥验证的常见问题
问：虚拟机引导加密会影响日常运维效率吗？
答：如果配置了vTPM自动解锁，运维人员基本无感知，但如果只靠手动输密码，服务器非预期重启时会卡在引导阶段，比较合理的方式是生产虚拟机全部引入vTPM自动解锁,开发测试环境保持手动交互式密码。
问：虚拟机加密后磁盘性能损失大不大？
答：现代CPU普遍支持AES-NI指令集，LUKS和BitLocker都能通过硬件加速分担加解密开销，多数情况下损失在个位数百分比到一成左右，数据密集型或大量随机读写的业务,建议先用真实负载压测再推广到线上环境。
问：虚拟机加密之后还支持在线迁移吗？
答：支持，只要虚拟机所在集群都配置了相同KMS，vCenter或ESXi会自动完成密钥传递，迁移后虚拟机能正常启动，若迁移后发现VMware虚拟机无法自动解锁，先排查目标集群是否已添加对应的密钥管理服务器,再考虑vTPM状态是否遭到重置。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/623257.html
