网络安全认证鉴权运维后端【免费下载链接】teleportThe easiest, and most secure way to access and protect all of your infrastructure.项目地址https://gitcode.com/gh_mirrors/tel/teleport点击查看免费下载Teleport 的 PagerDuty 访问请求插件Access Request Plugin将 Teleport 中的资源/角色访问请求Access Request与 PagerDuty 故障事件Incident打通每当用户发起权限提升请求插件自动在指定 PagerDuty 服务上创建一条 Incident 并通知值班团队审批人可以直接跟进而插件还会在请求被批准、拒绝、过期后同步关闭对应 Incident更进一步它还可以根据 PagerDuty 的 on-call 排班表自动批准请求让正在处理事故的值班工程师无需等待人工审批即可拿到基础设施权限。读完本文你将掌握该插件的架构原理、配置项含义、RBAC 资源定义、部署与运行方式以及如何借助仓库内的源码与测试理解其内部行为。插件是什么以事件驱动权限审批根据 integrations/access/pagerduty/README.md 的定位Teleport Access API 提供了一款 PagerDuty 访问请求插件它允许你把 Teleport 的资源/角色访问请求视为 PagerDuty Incident将 Incident 通知发送给合适的团队尤其是值班团队通过 PagerDuty 侧的操作直接批准或拒绝请求以及自动批准。该插件位于仓库的integrations/access/pagerduty目录属于 Teleport Access API 的官方集成之一。官方配置指南见 docs/pages/identity-governance/access-requests/plugins/pagerduty.mdx强调其典型价值工程师在解决故障时可以按需获取基础设施权限而不需要常驻管理员权限从而缩小攻击面。架构与工作流程插件自身是一个独立进程运行在你的私有网络中通过 Teleport Identity File身份文件与 Teleport 集群建立 gRPC 连接同时通过 REST API 与 PagerDuty API 交互。整体架构如下从图中可以看到三条关键链路插件通过反向隧道监听来自 Teleport Auth Service 的访问请求事件LISTEN FOR ACCESS REQUESTS并回写请求状态MODIFY ACCESS REQUESTS插件调用 PagerDuty API 发送通知、读取 Incident 状态SEND NOTIFICATIONS AND GET INCIDENT STATUSTeleport 集群内部Proxy Service 与 Auth Service 之间通过 gRPC 通信完成身份认证与访问控制。从源码看app.go 中的App.run会启动一个 watcher订阅KindAccessRequest与KindAccessMonitoringRule两类事件app.go#L115-L118随后根据事件类型分别处理。插件的核心状态机在 app.go 中体现为onPendingRequest请求进入 PENDING 状态时先尝试创建通知 Incident再尝试自动批准onResolvedRequest请求被批准/拒绝/升级时向 Incident 追加评审与结论 Note并关闭 IncidentonDeletedRequest请求过期被删除时以expired标记关闭对应 Incident。一次完整的请求生命周期结合源码与官方文档一次典型的交互流程如下用户例如myuser发起访问editor角色的请求Teleport Auth Service 根据用户角色的annotations为请求打上系统注解插件监听到 PENDING 请求读取pagerduty_notify_service注解定位目标服务调用 CreateIncident 创建标题为Access request from user、incident_key为teleport-access-request/reqID的 Incident审批人或自动批准逻辑在 Teleport 侧评审/批准/拒绝请求插件通过 ResolveIncident 将 Incident 状态置为resolved并追加一条说明“Access request has been approved/denied/expired”的 Note。运行后你可以在 PagerDuty 控制台看到形如下图的 Incident仓库中的插件实现结构integrations/access/pagerduty目录是插件的完整 Go 实现关键文件如下文件职责cmd/teleport-pagerduty/main.go命令行入口提供configure、version、start三个子命令cmd/teleport-pagerduty/example_config.toml随二进制嵌入的示例配置teleport-pagerduty configure直接输出它config.go配置结构定义、默认值填充与校验app.go核心业务逻辑事件处理、创建/关闭 Incident、自动批准client.go基于 resty 封装的 PagerDuty REST API 客户端types.goPagerDuty API 的请求/响应类型定义plugindata.go插件状态数据PluginData的编解码testlib/集成测试套件与 Fake PagerDuty 服务从 main.go#L41-L71 可以看到命令行行为teleport-pagerduty configure打印示例 TOML 配置start通过--config默认/etc/teleport-pagerduty.toml加载配置并启动-d开启调试日志。配置详解最小配置示例插件使用 TOML 格式配置文件官方示例见 examples/resources/plugins/teleport-pagerduty-cloud.toml# example teleport-pagerduty configuration TOML file [teleport] auth_server myinstance.teleport.sh:443 # Teleport Cloud proxy HTTPS address identity /var/lib/teleport/plugins/pagerduty/identity # Identity file path refresh_identity true # Refresh identity file periodically [pagerduty] api_key key # PagerDuty API Key user_email meexample.com # PagerDuty bot user email (Could be admin email) [log] output stderr # Logger output. Could be stdout, stderr or /var/lib/teleport/pagerduty.log severity INFO # Logger severity. Could be INFO, ERROR, DEBUG or WARN.配置字段与默认值config.go 中的Config.CheckAndSetDefaults定义了完整的默认值逻辑pagerduty.api_key必填。如果以/开头会被当作文件路径从该文件读取密钥config.go#L111-L116便于密钥落盘管理pagerduty.user_email必填PagerDuty 机器人用户的邮箱。创建 Incident 时该用户被记录为创建者对应 client.go#L185 的From请求头pagerduty.notify_service可选的注解名默认pagerduty_notify_service用于指定“收到新请求时通知哪个服务”pagerduty.services可选的注解名默认pagerduty_services用于指定“哪些服务的值班成员可以自动批准”API 端点默认https://api.pagerduty.comlog.output默认stderrlog.severity默认info。[teleport]段的连接方式有两种详见 example_config.toml 中的注释--formatfile使用identity身份文件可配refresh_identity true周期性刷新--formattls使用client_key、client_crt、root_cas三件套证书。addr指向 Auth Server默认端口 3025或 Proxy3080/443Teleport Cloud 场景下形如your-account.teleport.sh:443。核心机制一基于注解的通知路由插件不依赖固定的服务名而是读取访问请求上的系统注解来决定行为。官方部署指南在 pagerduty.mdx 中给出了角色定义示例kind: role version: v5 metadata: name: editor-requester spec: allow: request: roles: [editor] thresholds: - approve: 1 deny: 1 annotations: pagerduty_notify_service: [Teleport Access Request Notifications]当用户以该角色发起请求时Auth Service 会把注解写入请求的系统注解system annotations。插件在 getNotifyServiceName 中读取pagerduty_notify_service注解的第一个值再通过 FindServiceByName大小写不敏感定位 PagerDuty 服务并创建 Incident。若注解缺失或为空插件会跳过通知以errSkip静默处理app.go#L315-L318因此没有配置通知的服务不会产生噪音。核心机制二基于 on-call 排班的自动批准对于应急场景插件支持“谁值班谁放行”当请求注解pagerduty_services列出的服务中有某个服务的升级策略Escalation Policy里包含当前请求用户且该用户处于 on-call 状态时插件会自动以插件用户身份提交一条 APPROVED 评审。官方文档的示例角色如下pagerduty.mdx#L149-L181kind: role version: v5 metadata: name: demo-role-requester spec: allow: request: roles: [demo-role] thresholds: - approve: 1 deny: 1 annotations: pagerduty_services: [My Critical Service]自动批准的前提条件来自源码 tryApproveRequest请求注解pagerduty_services必须存在请求用户的 Teleport 用户名必须是合法邮箱且能在 PagerDuty 中按邮箱找到对应用户FindUserByEmail该用户在注解列出的某个服务的升级策略中处于 on-callFilterOnCallPolicies 通过/oncalls接口分页校验插件用户必须拥有评审这些请求的权限见下文 RBAC。满足条件后插件提交的评审理由形如Access requested by user name (email) who is on call in service(s) service1,service2值得注意的是插件会跳过“不是为注解中列出的服务值班”的用户即使该用户在其他服务的升级策略中 on-call也不会触发批准这正是 suite.go 中TestAutoApprovalWhenOnCallInSomeOtherPolicy的测试意图。核心机制三Incident 状态同步与评审回填请求被批准、拒绝或过期后插件会自动同步 PagerDuty 侧状态onResolvedRequestapp.go#L325-L342根据请求最终状态APPROVED / DENIED / PROMOTED构造ResolutionResolveIncident 先向 Incident 追加一条结论 Note如Access request has been approved附上原因再把 Incident 的status更新为resolved请求过期被删除时onDeletedRequest以expired标记关闭 Incidentapp.go#L344-L346。此外多人评审场景下插件的 postReviewNotes 会把每一位评审人的结论追加为 Incident Note内容格式见 client.go#L57-L65Author reviewed the request at time. Resolution: APPROVED. Reason: reason.评审进度的去重依赖插件数据PluginData中的reviews_count计数避免重复追加 Note。插件状态存储PluginData插件会把每个请求的关联状态创建的 Incident ID、服务 ID、用户、角色、创建时间、评审计数、最终决议写入 Teleport 的 access request plugin data。定义与编解码见 plugindata.goRequestDatauser、roles、created、request_reason、reviews_count、resolution 等字段PagerdutyDataservice_id、incident_id。写入通过modifyPluginDataapp.go#L639-L675执行“读取-比较-交换”的乐观锁更新compare-and-swap冲突时使用指数退避重试保证并发场景下例如多个事件同时到达PluginData 的一致性。测试套件中的TestRace正是通过大量并发请求验证这一行为。部署从 RBAC 到运行1. 定义 RBAC 资源除请求者角色外还需要为插件本身准备账号。官方文档pagerduty.mdx#L199-L321定义了两个角色和一个用户kind: role version: v5 metadata: name: access-plugin spec: allow: rules: - resources: [access_request] verbs: [list, read] - resources: [access_plugin_data] verbs: [update] review_requests: roles: [demo-role] where: contains(request.system_annotations[pagerduty_services], My Critical Service) --- kind: user metadata: name: access-plugin spec: roles: [access-plugin] version: v2其中review_requests.where谓词表达式限制了插件只能评审“注解pagerduty_services包含My Critical Service”的请求这是一种最小权限约束。kind: role version: v5 metadata: name: access-plugin-impersonator spec: allow: impersonate: roles: - access-plugin users: - access-plugin然后使用tctl create -f ...创建以上资源并把自己账号加入editor-reviewer、access-plugin-impersonator、demo-role-requester等角色最后创建用于演示的请求者用户$ tctl create -f editor-request-rbac.yaml $ tctl create -f demo-role-requester.yaml $ tctl create -f access-plugin.yaml $ tctl create -f access-plugin-impersonator.yaml $ tctl users add myuser --roleseditor-requester2. 导出插件身份插件需要一个 Teleport 身份文件来认证。生产环境推荐使用 Machine IDtbot签发短期身份文件演示环境也可以用tctl导出长期身份文件具体以 tbot-identity.mdx 与 identity-export.mdx 两个 include 文档为准。3. 生成 PagerDuty API Key在 PagerDuty 控制台进入Integrations → API Access Keys创建 API Key不要勾选 Read-only。账号需要具备 “Admin”、“Global Admin” 或 “Account Owner” 基础角色以便列出和查询用户资料。Key 将填入配置文件的pagerduty.api_key。4. 生成并编辑配置在插件主机上执行$ teleport-pagerduty configure teleport-pagerduty.toml $ sudo mv teleport-pagerduty.toml /etc插件默认读取/etc/teleport-pagerduty.toml也可用--config覆盖。编辑后填入 Auth/Proxy 地址、身份文件路径与 PagerDuty 凭据。若使用 Helm 部署则通过teleport-plugin-pagerdutyChart 的 values 文件配置teleport.address、teleport.identitySecretName、pagerduty.apiKey、pagerduty.userEmail参见 examples/resources/plugins/teleport-pagerduty-helm-cloud.yaml 与 Helm 参考文档 teleport-plugin-pagerduty.mdx。5. 启动与验证可执行文件方式直接运行$ teleport-pagerduty start -dDocker 方式$ docker run -v path-to-config:/etc/teleport-pagerduty.toml public.ecr.aws/gravitational/teleport-plugin-pagerduty:(teleport.version) start启动日志会依次输出版本检查、请求 watcher 启动、PagerDuty API 健康检查调用/abilities见 HealthCheck与 watcher 连接成功。健康检查失败会提示“check your credentials and service_id settings”app.go#L210。6. systemd 托管生产环境建议用 systemd 托管仓库提供了官方 unit 文件 examples/systemd/plugins/teleport-pagerduty.service[Unit] DescriptionTeleport Pagerduty Plugin Afternetwork.target [Service] Typesimple Restarton-failure ExecStart/usr/local/bin/teleport-pagerduty start --config/etc/teleport-pagerduty.toml ExecReload/bin/kill -HUP $MAINPID PIDFile/run/teleport-pagerduty.pid [Install] WantedBymulti-user.target保存到/usr/lib/systemd/system/后执行$ sudo systemctl enable teleport-pagerduty $ sudo systemctl start teleport-pagerduty用测试理解行为边界integrations/access/pagerduty/testlib提供了非常完整的测试套件可作为理解插件行为的“活文档”TestIncidentCreation验证 Incident 创建到注解指定服务incident_key为teleport-access-request/reqID初始状态triggered且 Incident ID 回写 PluginDataTestApproval/TestDenial验证请求被批准/拒绝后Incident 追加相应 Note 并变为resolvedTestExpiration验证请求被删除模拟过期后Incident 以expired说明关闭TestAutoApprovalWhenOnCall/TestAutoApprovalWhenNotOnCall/TestAutoApprovalWhenOnCallInSomeOtherPolicy分别验证 on-call 自动批准、非 on-call 不批准、以及“在无关服务值班也不批准”的边界TestRecipientsFromAccessMonitoringRule验证访问监控规则Access Monitoring Rule也能作为通知服务来源TestRace并发风暴下插件数据的最终一致性。其中测试断言如 Note 内容必须包含 “Access request has been approved”、“Reason: okay”直接对应 client.go 中的三个模板incident body、review note、resolution note。延伸访问监控规则作为通知来源除了角色注解插件还支持通过 Access Monitoring Rule 指定通知对象。在 app.go#L178-L193 中插件为accessmonitoring.RuleHandler配置了FetchRecipientCallback将规则中的接收者schedule 类型映射为 PagerDuty 服务名。当请求命中规则时RecipientsFromAccessMonitoringRules返回的服务名优先级高于角色注解app.go#L348-L371。这与仓库文档 access-monitoring-rules.mdx 中描述的机制一致可让管理员用统一规则集中管理通知策略。小结Teleport PagerDuty 访问请求插件把“权限审批”无缝嵌入事故响应流程通过pagerduty_notify_service注解路由通知、通过pagerduty_services注解结合 on-call 排班实现自动批准、通过 Incident Note 回填评审过程、通过 PluginData 保证状态一致性。如果要在自己的 Teleport 集群中落地这套审批流可以直接参考 docs/pages/identity-governance/access-requests/plugins/pagerduty.mdx 的八步部署指南并结合本文的配置项与源码分析调整细节。赞分享网络安全认证鉴权运维后端【免费下载链接】teleportThe easiest, and most secure way to access and protect all of your infrastructure.项目地址https://gitcode.com/gh_mirrors/tel/teleport点击查看免费下载相关推荐Teleport 邮件访问请求插件teleport-email源码级指南基于 Access API 的审批邮件通知方案Teleport 邮件访问请求插件teleport email源码级指南基于 Access API 的审批邮件通知方案 Teleport 的 Access网络安全认证鉴权运维后端Teleport Opsgenie 插件集成实战从 plugin_service 配置到访问请求告警与自动审批Teleport Opsgenie 插件集成实战从 plugin_service 配置到访问请求告警与自动审批 导读 本文以 Teleport 仓库中的设计文网络安全认证鉴权运维后端Teleport Access Request Email 插件 Helm Chart 部署实战Kubernetes 上的访问请求邮件通知Teleport Access Request Email 插件 Helm Chart 部署实战Kubernetes 上的访问请求邮件通知 本文基于 Tele网络安全认证鉴权运维后端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考