EC2部署的Pentaho(PDI)如何调用AWS Secrets Manager数据库密码

1. 基础权限配置（跳过这步后面全白搭） #

• 绝对不要在EC2本地配置任何长期AWS AK/SK，直接给EC2绑定专属IAM实例角色，所有AWS服务调用全走实例角色的自动轮换临时凭证，凭证全程不落盘。
• 给这个角色附最小权限策略：只开放secretsmanager:GetSecretValue单个操作，资源范围严格限定到你存Pentaho数据库密码的特定Secret ARN，别图省事给Secrets Manager全权限，尽可能缩小风险面。
• 权限策略参考：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "secretsmanager:GetSecretValue",
            "Resource": "arn:aws:secretsmanager:<你的区域>:<你的AWS账号ID>:secret:<你的Secret名前缀>*"
        }
    ]
}

• 配完直接在EC2上执行aws secretsmanager get-secret-value --secret-id <你的Secret名> --query SecretString --output text，能正常返回Secret内容就说明权限通了，这步不需要在本地.aws目录下写任何凭证配置。
• 建议强制开EC2的IMDSv2模式，避免实例元数据被冒用，进一步收紧权限边界。

2. Secrets Manager侧配置 #

• 把Pentaho要用到的所有数据库连接信息按业务粒度存成独立Secret，比如按库实例命名为prod/pentaho/mysql_biz1、prod/pentaho/oracle_biz2，每个Secret存结构化键值对，包含username、password、host、port、dbname全量连接信息，后续拉取一次就能拿全所有参数，不用零散维护。
• 直接开Secrets Manager自带的自动轮换功能，配置对应数据库的轮换逻辑，后续密码到期自动更新，Pentaho侧拉到的永远是最新有效密码，不用人工改配置。

3. Pentaho PDI侧适配（核心：密码只走内存，绝不写磁盘） #

别用PDI自带的本地密码加密功能，那是固定密钥的对称加密，解密密钥就藏在PDI安装包的jar里，随便找个脚本就能破开，完全不符合无本地留存的要求。推荐用启动期内存注入变量的方案，改造量最小：

• 第一步：把所有PDI作业、转换里的数据库连接配置全部替换成变量引用，比如用户名填${DB_USER_BIZ1}、密码填${DB_PASS_BIZ1}、连接地址填${DB_HOST_BIZ1}，不要在PDI的kettle.properties或者任何本地配置文件里写死这些变量的值。
• 第二步：修改PDI的启动脚本，不管你是用carte.sh跑Carte服务，还是用pan.sh/kitchen.sh命令行跑转换/作业，在启动JVM进程之前加一段拉取Secret的逻辑，把拉到的连接参数直接设为当前shell进程的临时环境变量传给JVM，绝对不要把拉到的内容写入任何本地临时文件。
• 启动脚本里加的逻辑参考（Linux环境，提前装jq用来解析JSON即可）：

# 拉取对应业务库的Secret，直接解析为临时环境变量
SECRET_BIZ1=$(aws secretsmanager get-secret-value --secret-id prod/pentaho/mysql_biz1 --query SecretString --output text)
export DB_USER_BIZ1=$(echo $SECRET_BIZ1 | jq -r '.username')
export DB_PASS_BIZ1=$(echo $SECRET_BIZ1 | jq -r '.password')
export DB_HOST_BIZ1=$(echo $SECRET_BIZ1 | jq -r '.host')
export DB_PORT_BIZ1=$(echo $SECRET_BIZ1 | jq -r '.port')
export DB_NAME_BIZ1=$(echo $SECRET_BIZ1 | jq -r '.dbname')

# 后面接原来的PDI启动命令就行，进程退出后这些临时环境变量直接销毁，不会留任何痕迹

• 第三步：调整PDI日志级别，关闭变量明文打印，避免密码被输出到日志文件里造成泄露。

如果你那边作业量特别大、要连的库特别多，可以写个轻量的PDI自定义初始化步骤，在作业启动阶段直接用AWS SDK拉取对应Secret注入PDI变量空间，逻辑和上面的方案一致，只是把拉取逻辑从启动脚本移到了PDI插件内部，同样不会有本地落盘的问题。

4. 上线前校验 #

• 扫一遍PDI安装目录下所有配置文件、所有作业/转换文件，确认没有硬编码的明文/加密密码。
• 检查EC2上的~/.aws/目录，确认没有存任何长期AK/SK凭证文件，所有AWS调用全走实例角色。
• 跑一次测试作业后，用grep扫一遍EC2本地磁盘所有文件里的密码关键字，确认没有意外生成的包含密码的临时文件。

内容的提问来源于stack exchange，提问作者dobrzak