KEDA无法连接AWS MQ：用户名/密码验证403异常求助

以下是针对你遇到的认证错误的具体排查和修复步骤：

1. 紧急修复Secret中的Host配置错误 #

你的Secret里host字段的base64值G9zdA==解码后是**"host"**，这完全不是AWS MQ的实际连接地址。AWS MQ的RabbitMQ端点地址可在AWS控制台的MQ实例详情页获取，格式类似：b-xxxxxxx-xxxx-xxxx-xxxx-xxxxxxx.mq.us-east-1.amazonaws.com。

修复操作：

• 将正确的Host地址做base64编码，替换Secret中的host值：

  echo -n "你的AWS MQ实际地址" | base64
  

• 重新应用Secret：kubectl apply -f 你的Secret配置文件.yaml

2. 补充ScaledObject触发器的必要参数 #

你的ScaledObject的RabbitMQ触发器缺少两个关键参数：

• port: AWS MQ的AMQP TLS端口是5671，KEDA默认用5672，必须显式指定
• vhost: 默认是/，显式声明可避免潜在的默认值冲突

修改后的触发器配置片段：

triggers:
- type: rabbitmq
  metadata:
    mode: QueueLength
    value: "5" 
    queueName: keda
    protocol: amqp
    port: "5671"  # 指定AWS MQ的TLS端口
    vhost: "/"     # 显式声明默认vhost
  authenticationRef:
    name: aws-mq-auth

3. 验证RabbitMQ用户的权限 #

虽然能登录控制台，但AMQP连接需要用户拥有对应vhost和队列的权限：

• 登录AWS MQ的RabbitMQ控制台，进入Admin > Users找到你的用户
• 检查该用户在目标vhost（默认/）下的权限：至少需要configure、write、read权限（针对keda队列或.*匹配所有队列）
• 若权限不足，编辑用户权限，添加对应vhost的权限规则

4. 确认Secret编码的正确性 #

除Host外，也要验证用户名和密码的base64编码是否正确：

echo -n "Yg==" | base64 -d  # 应输出你的实际用户名
echo -n "RZg==" | base64 -d  # 应输出你的实际密码

若编码错误，重新生成正确的base64值并更新Secret。

5. 确认TLS配置有效性 #

你设置的tls: enabled（ZW5hYmxl解码正确）符合AWS MQ的TLS要求，KEDA的RabbitMQ scaler默认信任AWS根CA证书，无需额外配置CA证书，确保不要在触发器参数中添加多余的ca字段即可。

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