Velero备份失败若因AccessDenied或NoCredentialProviders，应优先检查Credentials Secret挂载、ServiceAccount RBAC权限及云平台IAM策略；执行velero backup describe与logs确认错误类型，再逐层验证凭证路径、Secret内容和权限配置。
当Velero备份任务卡在InProgress后突然变为Failed，且velero backup describe中显示Phase: Failed、Validation Errors: 0但日志里反复出现AccessDenied或NoCredentialProviders，基本可锁定为存储桶权限配置失效——这不是网络问题，也不是Velero服务端崩溃，而是凭证根本没被正确加载或无对应操作权限。
确认失败是否由权限引发
执行velero backup describe <backup-name></backup-name>，重点检查Conditions区块末尾是否含error: AccessDeniedException或error: NoCredentialProviders。若出现其中任一字符串，说明请求已抵达云厂商API网关并被明确拒绝，而非超时或连接失败——这一步必须做，否则后续所有排查都可能跑偏。
运行velero backup logs <backup-name></backup-name>，搜索关键词s3:GetObject、s3:PutObject、listKeys（Azure）、GetObjectAttributes（GCP）。只要看到某条操作返回403 Forbidden或404 Not Found（后者在Azure中常因权限不足导致资源不可见），即可100%确认是权限链路断裂。
验证凭证文件内容与挂载路径
方法一：直接检查Secret内容
执行kubectl get secret -n velero cloud-credentials -o jsonpath='{.data.cloud}' | base64 -d，核对输出中aws_access_key_id和aws_secret_access_key是否为真实有效值（非占位符如AKIA...后全X）。若输出为空或含***REDACTED***，说明Secret未正确创建或base64编码错误。
方法二：进入Velero Pod验证挂载
执行kubectl exec -it deploy/velero -n velero -- cat /credentials/cloud。如果报错No such file or directory，说明--secret-file参数指定的路径与Pod内实际挂载路径不一致——【Velero install命令中--secret-file路径必须指向宿主机上存在的文件，且该文件会被自动挂载到容器内/credentials/cloud】。
检查ServiceAccount与RBAC绑定
第一步：确认Velero使用的ServiceAccount名称
执行kubectl get deploy/velero -n velero -o jsonpath='{.spec.template.spec.serviceAccountName}'，默认为velero。若自定义过，请记录该名称。
第二步：检查该ServiceAccount是否绑定了足够权限
执行kubectl get rolebinding,clusterrolebinding -A | grep velero，找到绑定到上一步ServiceAccount的RoleBinding或ClusterRoleBinding。若无任何输出，说明RBAC未配置，Velero容器将无法读取Secret资源——这是90%权限失败的根源。
第三步：验证Secret读取权限是否生效
执行kubectl auth can-i get secret -n velero --as system:serviceaccount:velero:velero，返回yes才表示权限到位。若返回no，需立即应用官方RBAC清单：kubectl apply -f https://github.com/vmware-tanzu/velero/releases/download/v1.12.0/velero-v1.12.0-rbac.yaml。
云平台侧权限策略校验
方法一（AWS）：检查IAM Policy是否包含s3:ListBucket、s3:GetObject、s3:PutObject、s3:DeleteObject，且Resource字段精确匹配你的--bucket名称及路径前缀（如"arn:aws:s3:::velero-backup/*"）。漏掉ListBucket会导致Velero无法扫描已有备份快照，直接报错退出。
方法二（Azure）：登录Azure Portal → 打开对应Storage Account → “访问控制(IAM)” → 点击“角色分配” → 检查分配给Velero托管标识的角色是否为Storage Blob Data Contributor。若仅为Reader或Contributor，则不具备对象级读写权限，必然失败。
注意：Azure中若启用Pod Identity，必须确保Velero Pod的Label（如component: velero）与AzurePodIdentityException资源中podLabels字段完全一致，否则NMI代理会拦截所有IMDS请求，导致凭证刷新失败。
动态调试服务端凭证加载
临时将Velero服务端日志级别调至debug：kubectl patch deployment velero -n velero --type='json' -p='[{"op":"add","path":"/spec/template/spec/containers/0/args/-","value":"--log-level=debug"}]'。
等待Pod重启后，执行kubectl logs deploy/velero -n velero | grep -i "credential\|auth\|provider"。若输出中出现Using AWS credential provider chain但紧跟着NoCredentialProviders，说明SDK已尝试所有默认路径（EC2 metadata、SharedConfig、WebIdentity）均未命中——此时应立刻检查Secret挂载和ServiceAccount绑定，而非修改云平台策略。
