Airflow升级至2.9.3后SparkPodOperator报403权限错误求助

核心原因 #

错误日志明确指出：system:serviceaccount:airflow-v2:airflow-worker 没有权限获取 sparkoperator.k8s.io 组下的 sparkapplications/status 资源。当前配置的ClusterRole仅授权了sparkapplications主资源，未覆盖status子资源——Kubernetes中自定义资源的状态信息是独立的子资源，需要单独声明权限。此外，Airflow从2.3.0升级到2.9.3后，SparkPodOperator的逻辑新增了创建作业后查询状态的步骤，触发了之前未用到的权限检查。

排查与修复步骤 #

• 验证当前权限
  用kubectl直接检查服务账户的权限：

  kubectl auth can-i get sparkapplications/status --as=system:serviceaccount:airflow-v2:airflow-worker -n airflow-v2
  

  如果返回no，则确认是权限缺失问题。

• 更新ClusterRole配置
  修改ClusterRole，添加status子资源权限，两种方式任选其一：
  方式1：明确指定主资源和子资源

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRole
  metadata:
    name: spark-cluster-cr
    labels:
      rbac.authorization.kubeflow.org/aggregate-to-kubeflow-edit: "true"
  rules:
  - apiGroups:
    - sparkoperator.k8s.io
    resources:
    - sparkapplications
    - sparkapplications/status
    verbs:
    - "*"
  

  方式2：用通配符覆盖所有子资源

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRole
  metadata:
    name: spark-cluster-cr
    labels:
      rbac.authorization.kubeflow.org/aggregate-to-kubeflow-edit: "true"
  rules:
  - apiGroups:
    - sparkoperator.k8s.io
    resources:
    - sparkapplications/*
    verbs:
    - "*"
  

  应用更新：

  kubectl apply -f updated-clusterrole.yaml
  

• 验证权限修复
  再次执行之前的权限检查命令，确认返回yes，然后重新运行Airflow的Spark作业测试。

• 排查其他可能问题

  • 确认ClusterRoleBinding的subjects字段中，服务账户名称airflow-worker和命名空间airflow-v2完全正确，roleRef指向的ClusterRole名称spark-cluster-cr无误。
  • 如果权限仍不生效，检查是否存在命名空间级别的Role（而非ClusterRole），因为Role的优先级高于ClusterRole，可能覆盖了权限配置。
  • 查看Kubernetes审计日志，确认请求的资源、用户、命名空间是否与配置匹配，排查是否有其他RBAC规则限制了访问。

内容的提问来源于stack exchange，提问作者M. Ramalho