别再让开发等审批了：聊聊自动化权限申请与凭证发放，怎么真正提升 DX
做运维这些年，我见过一个特别离谱但又特别常见的场景。
一个开发同事，只是想访问一台测试服务器。
流程是这样的：
提工单 → 主管审批 → 运维审批 → 安全部门审批 → 创建账号 → 发密码
如果顺利的话，半天。
如果中间有人开会、出差、忘了点审批，两三天都有可能。
结果是什么？
开发同事只能干两件事：
1️⃣ 在群里疯狂 @ 运维
2️⃣ 借同事账号
于是你会发现：
- 账号共享
- 密码写在文档里
- SSH Key 满天飞
安全性没了，开发体验（DX）也没了。
所以很多团队这几年都在做一件事：
自动化权限申请 + 自动发放临时凭证
今天咱就聊聊这个话题。
说白了，这其实是 DevOps 和安全之间的一次握手。
一、DX 不只是开发体验，也包括权限体验
很多公司一提 DX（Developer Experience），想到的都是：
- CI/CD
- 自动部署
- 自动测试
但其实有一个特别影响体验的东西：
权限。
我见过很多公司权限是这样管理的：
| 资源 | 权限申请方式 |
|---|---|
| Git 仓库 | 找管理员 |
| Kubernetes | 提工单 |
| 数据库 | 发邮件 |
| 服务器 | 找运维 |
结果就是：
开发一天写代码，三天等权限。
如果你仔细观察会发现：
很多所谓的“效率问题”，其实是流程问题。
所以现代运维越来越强调一个理念：
权限也要像 API 一样申请。
二、自动化权限申请的基本架构
一个成熟的权限系统，一般长这样：
开发者
|
权限申请 Portal
|
审批引擎
|
权限控制服务
|
资源系统
(K8s / DB / Server / Git)
流程其实很简单：
申请 → 审批 → 自动发放 → 自动回收
重点是两件事：
自动发放
临时权限
很多公司最大的问题就是：
权限一给就是永久。
这才是安全最大的坑。
三、自动化权限申请 Portal（简单示例）
先看一个非常简单的权限申请 API。
from fastapi import FastAPI
import uuid
import datetime
app = FastAPI()
requests = {
}
@app.post("/request_access")
def request_access(user: str, resource: str, duration: int):
request_id = str(uuid.uuid4())
requests[request_id] = {
"user": user,
"resource": resource,
"duration": duration,
"status": "pending",
"time": datetime.datetime.now()
}
return {
"request_id": request_id,
"message": "Access request submitted"
}
开发者只需要调用：
POST /request_access
提交：
user = alice
resource = k8s-prod
duration = 2h
权限申请就进入审批流程。
这一步其实不复杂，复杂的是后面的：
权限自动发放。
四、自动发放凭证：别再手动建账号了
很多运维每天都在干一件很机械的事情：
创建账号
分配权限
发密码
这种事情其实完全可以自动化。
比如我们用 SSH 临时证书。
先生成一个临时 SSH Key：
ssh-keygen -t rsa -f temp_key
然后用 CA 签发证书：
ssh-keygen -s ca_key \
-I alice \
-n alice \
-V +2h \
temp_key.pub
这里有一个关键参数：
-V +2h
意思是：
2小时后自动失效。
这就比传统账号安全太多了。
开发者只需要：
ssh -i temp_key server
就可以登录。
2小时后：
权限自动消失。
五、Kubernetes 权限自动发放
Kubernetes 权限其实也可以自动控制。
比如审批通过后，系统自动创建 RoleBinding。
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: temp-access-alice
namespace: production
subjects:
- kind: User
name: alice
roleRef:
kind: Role
name: read-only
apiGroup: rbac.authorization.k8s.io
然后设置一个 TTL 任务：
kubectl delete rolebinding temp-access-alice --after=2h
或者更优雅一点，用控制器自动清理。
这样权限生命周期就变成：
审批通过
↓
自动创建 RBAC
↓
到期自动删除
整个过程：
运维不需要参与。
六、自动回收权限才是关键
很多系统只做了前半段：
自动申请
自动审批
但最重要的一步没做：
自动回收。
我见过很多公司 Kubernetes 里：
RoleBinding 2000+
结果一查：
80% 是早就不用的权限。
这就像什么？
就像你给别人家门钥匙，但从来不收回来。
正确做法是：
所有权限必须有 TTL。
例如：
1小时
4小时
1天
到期自动失效。
这样安全性和 DX 才能同时提高。
七、真正成熟的权限系统长什么样？
如果一个团队权限体系成熟，一般会有几个特征。
1 权限申请自助化
开发者自己申请：
Portal
CLI
API
不需要找人。
2 权限自动发放
审批完成：
自动创建账号
自动生成凭证
自动配置 RBAC
没有人工操作。
3 权限自动回收
所有权限都有：
TTL
到期自动清理。
4 权限可审计
所有操作都有日志：
谁申请
谁审批
谁使用
什么时候过期
安全部门最喜欢这种。
八、说点我自己的感受
做运维久了，你会慢慢发现一件事：
很多所谓的“安全流程”，其实只是人为制造摩擦。
安全的本质从来不是：
让人更难做事
而应该是：
让正确的事情更容易
如果开发者申请权限很难，他们就会：
- 共享账号
- 偷用权限
- 写死密码
这反而更危险。
真正好的系统应该是：
申请权限很容易
但权限是临时的
换句话说就是：
降低摩擦，提高约束。
当权限系统做到自动化以后，你会发现一个特别有意思的变化：
开发不再抱怨运维慢。
运维也不再天天发账号。
整个团队效率都会提高。
