KooCLI 多环境配置隔离：别让测试账号的密钥跑到生产里

问题从哪来

开发、测试、生产三套环境，每套一组 AK/SK，再加一个临时排查用的只读账号。如果全部塞进同一份默认配置里，靠「记得改回来」来保证安全，那迟早会出事——最典型的事故是拿测试环境的密钥去删生产资源，或者反过来把测试数据写进生产库。

KooCLI 的 profile 机制就是为这个场景设计的：把「一组凭证 + 一个区域 + 一个项目」打包成命名配置，用一次参数切换整体上下文。

配置存放的位置

KooCLI 的配置默认落在用户目录下的隐藏目录里，跨平台路径不同，但逻辑一致：

# 查看当前生效的配置路径
hcloud configure list

# 交互式初始化一组新凭证
hcloud configure init --profile=prod
hcloud configure init --profile=test

初始化时会依次要求输入 AK、SK、区域（region）和项目 ID（project_id）。这里有两个容易忽略的点：

• region 和 project_id 是配置的一部分，不只是请求参数。切换 profile 会同时切换它们，这既是便利也是风险——如果某条命令没写 --cli-region，用的就是 profile 里的值。
• AK/SK 是明文存储的，配置文件权限默认只有当前用户可读，但不要把它放进代码仓库，也不要在共享机器上留生产凭证。

切换与校验

临时切换用 --cli-profile，长期切换用默认 profile 设置：

# 单次命令指定
hcloud ECS ListServersDetails --cli-profile=test

# 改默认 profile
hcloud configure set --cli-profile=prod

# 确认当前上下文（这一步养成习惯）
hcloud configure list --cli-profile=prod | head -20

建议在每个脚本开头显式写 --cli-profile，不要依赖默认值。脚本是要被别人执行、被定时任务执行的，默认值在另一个人的机器上可能是另一个账号。

三个真实会咬人的坑

1. 全局服务需要额外的 domain id

ECS、VPC 这类区域级服务只需要 region；但账单、IAM 这类全局服务，请求需要落到账号维度，光有 region 不够。实际表现是命令报错但错误信息不指向根因。遇到全局服务的调用失败，先检查是否需要补 --cli-domain-id，而不是怀疑密钥错了。

2. 代理会污染所有请求

如果机器上设置了 HTTP_PROXY 指向一个不可用的本地代理，KooCLI 的所有请求都会走代理然后超时，错误表现是 TLS handshake timeout 或者莫名其妙的 403。排查时先清掉代理环境变量：

unset HTTP_PROXY HTTPS_PROXY http_proxy https_proxy
export NO_PROXY='*'

这个问题在装了各种代理工具的办公机上出现频率极高，而且错误信息完全误导人。

3. 输出格式决定了能不能被脚本消费

默认输出是给人和给终端看的表格，带颜色和自动换行。要放进脚本处理，必须显式指定机器可读格式：

hcloud ECS ListServersDetails --cli-output=json --cli-query="servers[].{id:id,name:name,status:status}"

--cli-query 用的是 JMESPath 语法，能在客户端就把结果裁成需要的形状，比拉回全量再处理要省事得多。

给团队用的实践

如果是多人协作，建议做两件事：

1. 把 profile 命名规范写进 README：dev / test / prod / ro（只读），不允许自创名字。
2. 生产 profile 不在开发机上配置：需要动生产时走跳板机或 CI，本地只留 dev/test。这样即使本地凭证泄露，影响面也有限。

另外，长期凭证本身就是一个风险点。条件允许的话，用 IAM 的临时凭证替换长期 AK/SK，把有效期压到小时级，配合 profile 使用——KooCLI 支持通过环境变量注入临时凭证，配置里就不需要落长期密钥了。

小结

profile 机制解决的是「上下文切换」的一致性问题，它不会自动帮你防错。真正的防线是：脚本显式声明 profile、生产凭证不落开发机、全局服务的参数单独确认。这三条做到，跨环境误操作的概率会降一个数量级。