Velero 1.14.1 AWS插件IRSA角色使用问题解析

问题背景

在使用Velero 1.14.1版本配合aws插件1.10.1时，用户发现系统错误地使用了EC2工作节点的IAM角色而非通过IRSA（IAM Roles for Service Accounts）分配给服务账户的角色。这导致访问S3存储桶时出现403权限拒绝错误。

技术细节分析

IRSA是AWS EKS提供的一种机制，允许将IAM角色直接关联到Kubernetes服务账户。当Pod使用该服务账户运行时，会自动获得关联IAM角色的权限凭证。这种机制比传统的工作节点IAM角色更安全，可以实现更细粒度的权限控制。

在用户案例中，Velero服务账户已正确配置了eks.amazonaws.com/role-arn注解，理论上应该使用指定的IAM角色。但日志显示实际使用的是工作节点角色，这表明IRSA机制未被正确触发。

问题根源

经过社区讨论，发现问题出在Helm chart配置上。当同时满足以下两个条件时会导致此问题：

1. 在Helm chart中显式设置了credentials.useSecret: true（默认值）
2. 同时配置了IRSA

这种情况下，Velero会优先尝试使用Secret中的凭证，而不会使用IRSA提供的角色凭证。即使Secret不存在，这种行为也会阻止IRSA的正常工作。

解决方案

要确保IRSA正常工作，需要在Helm chart中明确禁用Secret凭证的使用：

credentials:
  useSecret: false

这个配置明确告诉Velero不要尝试使用Secret中的凭证，从而让IRSA机制能够正常工作。

最佳实践建议

1. 在使用IRSA时，始终设置credentials.useSecret: false
2. 确保EKS集群的OIDC提供商已正确配置
3. 验证服务账户的注解是否正确设置
4. 确认关联的IAM角色具有必要的S3权限（ListBucket, PutObject等）
5. 考虑在IAM策略中添加条件限制，确保角色只能被特定的服务账户担任

总结

Velero与AWS的集成提供了多种身份验证方式，但在同时配置多种方式时可能会出现优先级问题。通过理解各种认证机制的工作原理和交互方式，可以避免类似问题。对于使用EKS IRSA的用户，明确禁用其他认证方式是确保系统按预期工作的关键步骤。