Kube-Hetzner 项目中 SELinux 导致 K3s 服务启动失败的解决方案

问题背景

在使用 Terraform 部署 Kube-Hetzner 项目时，用户遇到了 K3s 服务无法启动的问题。具体表现为控制节点上的 K3s 服务启动失败，系统日志显示权限被拒绝的错误信息。这个问题在多个用户的部署过程中重复出现，影响了集群的正常初始化。

错误现象

当用户执行 terraform apply 命令部署集群时，控制平面节点上的 K3s 服务无法正常启动。系统日志中可以看到以下关键错误信息：

k3s.service: Failed to locate executable /usr/local/bin/k3s: Permission denied
k3s.service: Failed at step EXEC spawning /usr/local/bin/k3s: Permission denied

尽管检查文件权限显示 /usr/local/bin/k3s 确实属于 root 用户和 root 组，且手动执行该二进制文件可以正常工作，但通过 systemd 启动时仍然失败。

根本原因分析

经过深入调查，发现问题与 SELinux 安全机制有关。SELinux 是 Linux 的一个安全模块，它通过为系统中的对象（如文件、进程等）分配安全上下文来实施强制访问控制。

通过检查 SELinux 的审计日志，可以清楚地看到问题的根源：

type=AVC msg=audit(1704401173.178:542): avc: denied { execute } for pid=2234 comm="(k3s)" name="k3s" dev="sda3" ino=279 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=0

这条日志表明，SELinux 阻止了 systemd（运行在 init_t 上下文中）执行被标记为 user_tmp_t 类型的 K3s 二进制文件。

解决方案

临时解决方法

对于已经出现问题的节点，可以通过以下命令修复：

sudo restorecon -v /usr/local/bin/k3s

这个命令会恢复 /usr/local/bin/k3s 文件的默认 SELinux 安全上下文，使其能够被 systemd 正常执行。

永久解决方案

项目维护者已经在 v2.11.4 版本中修复了这个问题。用户可以通过以下步骤升级：

1. 更新项目代码
2. 执行 terraform init -upgrade
3. 重新部署集群

新版本中包含了自动修复 SELinux 上下文的功能，确保 K3s 二进制文件具有正确的安全标签。

技术细节

SELinux 上下文恢复

restorecon 命令的作用是根据系统策略恢复文件的安全上下文。它会检查文件的默认上下文规则，并将文件标记为适当的类型。对于 K3s 二进制文件，正确的上下文类型应该是 bin_t 或类似的类型，而不是 user_tmp_t。

为什么手动执行可以工作

当用户手动执行 K3s 二进制文件时，它运行在用户的终端上下文中（通常是 unconfined_t），这个上下文通常有更高的权限，不受 SELinux 限制。而 systemd 服务运行时使用的是 init_t 上下文，受到更严格的安全策略限制。

最佳实践建议

1. 定期更新：保持 Kube-Hetzner 项目代码为最新版本，以获取最新的修复和改进。
2. 监控 SELinux 日志：在部署过程中遇到权限问题时，应首先检查 SELinux 审计日志。
3. 理解安全机制：在生产环境中部署 Kubernetes 集群时，管理员应具备基本的 SELinux 知识，以便快速诊断和解决类似问题。

总结

SELinux 安全机制导致的 K3s 服务启动失败是一个常见但容易被忽视的问题。通过理解 SELinux 的工作原理和掌握基本的故障排除技巧，管理员可以快速解决这类问题。Kube-Hetzner 项目团队已经在新版本中加入了自动修复机制，大大简化了部署过程。对于使用旧版本的用户，手动执行 restorecon 命令是一个有效的临时解决方案。