Airflow迁移至EKS遇权限问题：ServiceAccount配置后仍报匿名用户403

核心问题分析 #

日志显示system:anonymous用户无权限操作blue-analytics命名空间的Pods，说明Airflow Pod未正确关联指定的ServiceAccount（airflow-pod-mgr），或RBAC权限的作用范围与实际操作的命名空间不匹配。

分步排查与修复 #

1. 确认Airflow Pod已绑定目标ServiceAccount #

检查Airflow Worker/Scheduler Pod的配置，确保serviceAccountName已设置为airflow-pod-mgr：

• 执行命令查看Pod的ServiceAccount：

  kubectl describe pod <airflow-worker-pod-name> -n namespace
  

• 查看输出中ServiceAccount字段，若不是airflow-pod-mgr，则修改Airflow的Deployment配置：

  spec:
    template:
      spec:
        serviceAccountName: airflow-pod-mgr  # 添加此行
        # 其他原有配置...
  

• 重启Pod使配置生效：

  kubectl rollout restart deployment <airflow-worker-deployment> -n namespace
  kubectl rollout restart deployment <airflow-scheduler-deployment> -n namespace
  

2. 修正RBAC权限的命名空间匹配 #

当前Role仅作用于namespace命名空间，但错误显示Airflow需要操作blue-analytics命名空间的Pods，需调整RBAC配置：

方案一：针对单个命名空间配置权限

在blue-analytics命名空间创建Role和跨命名空间RoleBinding：

# blue-analytics命名空间的Role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: blue-analytics
  name: airflow-pod-mgr-role
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["*"]
---
# 绑定原命名空间的ServiceAccount到blue-analytics的Role
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: airflow-pod-mgr-cross-ns-binding
  namespace: blue-analytics
subjects:
  - kind: ServiceAccount
    name: airflow-pod-mgr
    namespace: namespace  # SA所在的原命名空间
roleRef:
  kind: Role
  name: airflow-pod-mgr-role
  apiGroup: rbac.authorization.k8s.io

方案二：跨多命名空间配置权限（使用ClusterRole）

若Airflow需要操作多个命名空间的Pods，改用ClusterRole和ClusterRoleBinding：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: airflow-pod-mgr-clusterrole
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["*"]
    # 可选：限制到特定命名空间
    # namespaces: ["blue-analytics", "namespace"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: airflow-pod-mgr-clusterbinding
subjects:
  - kind: ServiceAccount
    name: airflow-pod-mgr
    namespace: namespace
roleRef:
  kind: ClusterRole
  name: airflow-pod-mgr-clusterrole
  apiGroup: rbac.authorization.k8s.io

3. 确保in_cluster配置正确生效 #

• 手动部署场景：确认airflow.cfg的[kubernetes] section中in_cluster = true，并重启Scheduler和Worker。
• Helm部署场景：在values.yaml中配置：

  kubernetes:
    in_cluster: true
  

  执行升级命令：

  helm upgrade airflow apache-airflow/airflow -n namespace -f values.yaml
  

4. 验证Pod内的ServiceAccount凭证 #

进入Airflow Worker Pod，检查是否已正确挂载ServiceAccount凭证：

kubectl exec -it <airflow-worker-pod> -n namespace -- bash
# 检查凭证文件是否存在
ls /var/run/secrets/kubernetes.io/serviceaccount/

需看到token、ca.crt、namespace三个文件，否则说明Pod未正确关联ServiceAccount，需回到步骤1重新检查配置。

5. 测试权限有效性 #

在Pod内执行以下命令测试API权限：

curl -k -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" https://kubernetes.default.svc/api/v1/namespaces/blue-analytics/pods

若返回Pod列表，则权限配置正确，重新运行DAG即可。

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