使用 systemd 将 Teleport Machine IDtbot部署为系统服务配置、权限初始化与开机自启【免费下载链接】teleportThe easiest, and most secure way to access and protect all of your infrastructure.项目地址: https://gitcode.com/gh_mirrors/tel/teleport导读本文围绕仓库中的 systemd 部署示例 展开讲解如何把 Teleport Machine ID即tbot机器人服务以 systemd 单元的形式部署到 Linux 主机上从编写/etc/tbot.yaml配置、用tbot init规划证书目录的读写权限到安装并启动machine-id.service服务实现守护与开机自启。读完本文你将掌握一套可在生产环境直接落地、可复制可排障的 tbot systemd 部署流程并能结合仓库源码理解每一步背后的参数语义与权限模型。说明本目录下的指南是速成参考聚焦于让服务跑起来。关于 Machine ID 的完整架构与配置说明包括多种 join 方式、输出服务类型、凭据生命周期等请以仓库根目录的 README 与 tbot 源码 为准。第一步编写 tbot 配置文件/etc/tbot.yaml示例中tbot以配置文件模式启动tbot start -c /etc/tbot.yaml因此第一步是创建并填写/etc/tbot.yamlauth_server: auth.example.com:3025 onboarding: join_method: token token: 00000000000000000000000000000000 ca_pins: - sha256:1111111111111111111111111111111111111111111111111111111111111111 storage: directory: /var/lib/teleport/bot destinations: - directory: /opt/machine-id这份配置对应 BotConfig 的顶层结构各字段含义如下配置项作用说明auth_server指定 Auth Server 的地址格式为host:porttbot 将直接与 Auth Server 通信完成加入与续期。对应的 Go 字段为AuthServer string \yaml:auth_server,omitemptyonboarding.join_method节点加入方式示例使用token即一次性 Join Token。从源码看合法值需命中onboarding.SupportedJoinMethods否则CheckAndSetDefaults会以unrecognized join method报错见 config.goonboarding.tokenJoin Token 值通过tctl tokens add --typenode生成的真实 token 替换示例中的全零占位串onboarding.ca_pinsAuth Server CA 指纹校验可选用于在加入时校验 Auth Server 的 CA 指纹抵御中间人攻击。与insecure选项互斥若同时配置会报the option ca-pin is mutually exclusive with --insecure见 config.gostorage.directorytbot 内部凭据存储目录存放 tbot 自身持有的长期凭据与内部状态。默认路径为filepath.Join(defaults.DataDir, bot)即/var/lib/teleport/bot见 config_storage.go示例显式指定了该默认路径destinations证书输出目录tbot 将产出的短期证书写入此处供业务方示例中是jenkins用户读取使用值得补充的是auth_server与proxy_server二选一即可。从 ConnectionConfig 的实现看proxy_server优先于auth_server未设置任何地址时连接配置会缺少目标地址。此外tbot的存储与目标目录都通过 destination 抽象 支持多种后端如目录、Kubernetes Secret示例中的directory:即目录型后端的最简写法。关于destinations的版本说明示例配置中的destinations是顶层简写形式。从 BotConfig 源码可见配置已从旧版outputs迁移到servicesCheckAndSetDefaults会执行conf.Services append(conf.Services, conf.Outputs...)完成自动迁移。因此在实际使用中你既可以使用面向服务的services语法声明ssh、kubernetes、application、database、workload_identity等输出类型也可以按本示例的简化方式配置目标目录。具体输出服务的类型清单可查看 lib/tbot/services 目录下的实现。第二步创建运行用户与初始化目标目录权限tbot应作为非 root 用户运行。示例约定运行用户teleport负责写证书、运行服务读取用户jenkins业务侧读取证书的账号如 CI 构建机上的 Jenkins agent首先创建用户并确保该用户对存储目录/var/lib/teleport/bot具备读写权限$ sudo useradd --system --home-dir /var/lib/teleport --shell /sbin/nologin teleport $ sudo mkdir -p /var/lib/teleport/bot $ sudo chown teleport:teleport /var/lib/teleport/bot然后使用tbot init初始化证书输出目录的属主与访问控制$ sudo tbot init \ --destination-dir/opt/machine-id \ --ownerteleport:teleport \ --bot-userteleport \ --reader-userjenkinstbot init对应仓库中的 InitCommand各参数语义如下均可在源码的 flag 定义中找到原始描述参数作用--destination-dir要初始化的证书输出目录路径--owner目录的 Linuxuser:group属主默认取当前运行tbot的 Linux 用户--bot-user启用 POSIX ACL声明可向目录读写短期证书的用户即teleport--reader-user启用 POSIX ACL声明可只读短期证书的用户即jenkins--init-dir当使用配置文件且配置了多个目标目录时指定本次要配置哪一个--clean若设置会清理目标目录中多余的文件与子目录这样做的意义在于分离写权限与读权限。teleport负责向/opt/machine-id写入证书jenkins只读证书而不具备写权限从而缩小了攻击面——即便读取方被攻破也无法篡改证书内容。从命令描述看init命令本身不需要 join 配置即可执行CheckAndSetDefaults中对 join 方法的校验也只在configure/start路径上强制因此可安全地在配置完成前先初始化目录。第三步安装并启动 systemd 服务仓库提供了开箱即用的服务单元文件 machine-id.service内容如下[Unit] DescriptionTeleport Machine ID Service Afternetwork.target [Service] Typesimple Userteleport Groupteleport Restartalways RestartSec5 ExecStart/usr/local/bin/tbot start -c /etc/tbot.yaml ExecReload/bin/kill -HUP $MAINPID PIDFile/run/machine-id.pid LimitNOFILE524288 [Install] WantedBymulti-user.target将该文件安装到 systemd 目录并启动服务$ sudo cp machine-id.service /etc/systemd/system/machine-id.service $ sudo systemctl daemon-reload $ sudo systemctl start machine-id $ sudo systemctl status machine-id服务单元关键点逐项解析Afternetwork.target确保网络就绪后再启动避免 tbot 在无法连接 Auth Server 时报错退出的竞态。Typesimpletbot start以前台进程方式常驻是简单型服务的最典型用法。Userteleport/Groupteleport以第二步创建的专用账号运行与tbot init中--bot-userteleport保持一致服务账号与 ACL 写权限账号必须是同一个用户。RestartalwaysRestartSec5进程异常退出后 5 秒自动拉起。对于依赖网络的守护型 bot 服务这一组合能显著提高可用性。ExecStart/usr/local/bin/tbot start -c /etc/tbot.yaml以配置模式启动-c指定配置文件也就是本文第一步创建的/etc/tbot.yaml。若tbot二进制不在该路径请相应调整。ExecReload/bin/kill -HUP $MAINPID向主进程发送SIGHUP触发重载。从 config.go 可以看到BotConfig预留了ReloadCh通道用于注入触发续期的信号这正与 systemd reload 机制呼应——通过systemctl reload machine-id可让 tbot 立即触发一次凭据续期而不必重启服务。PIDFile/run/machine-id.pid记录主进程 PID供 systemd 管理。LimitNOFILE524288将文件描述符上限提高到 524288避免长时间运行或高并发续期场景下因 fd 耗尽而失败。开机自启[Install]段的WantedBymulti-user.target声明了服务随多用户运行级别即正常开机启动。执行$ sudo systemctl enable machine-id即可在开机时自动拉起 Machine ID 服务。启用后可用systemctl status machine-id确认服务处于active (running)状态。运行后的验证与排障建议服务启动后可以从以下角度验证是否正常工作检查服务状态sudo systemctl status machine-id应显示active (running)若反复重启用sudo journalctl -u machine-id -f查看实时日志常见原因包括 join token 无效、auth_server不可达、存储目录无写权限。检查证书产出查看/opt/machine-id目录下是否有 tbot 写入的证书文件并确认jenkins用户可读$ sudo -u jenkins ls -l /opt/machine-id触发手动续期sudo systemctl reload machine-id通过ExecReload向进程发送SIGHUP可用于验证续期链路是否健康。需要留意的是示例将tbot二进制固定为/usr/local/bin/tbot证书默认 TTL 与续期间隔等参数源码默认值分别为DefaultCertificateTTL 60 * time.Minute、DefaultRenewInterval 20 * time.Minute见 config.go可通过配置文件中的credential_ttl/renewal_interval调整以满足不同业务场景对证书刷新频率的要求。小结本文基于仓库的 systemd 部署示例 完成了从零到一的完整落地编写/etc/tbot.yaml接入 Auth Server、配置 join token、规划存储与输出目录→ 创建专用运行用户并用tbot init建立bot 可写、业务方只读的权限模型 → 安装并启动machine-id.service实现守护、自动重启与开机自启。配合 machine-id.service、tbot 配置实现 与 tbot init 命令 的源码佐证这套流程既可直接照搬也具备按需调整的扩展空间——例如切换 join 方式、增加更多证书输出服务或自定义凭据生命周期。【免费下载链接】teleportThe easiest, and most secure way to access and protect all of your infrastructure.项目地址: https://gitcode.com/gh_mirrors/tel/teleport创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考