在Kubeflow Notebook调用KServe模型时遭遇RBAC权限拒绝问题求助

以下是针对你遇到的权限拒绝问题的可能原因及对应解决步骤：

1. Notebook服务账号缺少InferenceService访问权限 #

Kubeflow Notebook默认使用的服务账号可能未被授予访问目标命名空间下KServe资源的权限。

• 查看Notebook使用的服务账号：

  kubectl get pod <你的Notebook Pod名称> -n test-namespace -o jsonpath='{.spec.serviceAccountName}'
  

• 创建权限角色并绑定：
  先创建一个允许访问KServe资源的Role：

  apiVersion: rbac.authorization.k8s.io/v1
  kind: Role
  metadata:
    name: kserve-inference-access
    namespace: test-namespace
  rules:
  - apiGroups: ["serving.kserve.io"]
    resources: ["inferenceservices", "inferenceroutes"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["services"]
    verbs: ["get", "list", "watch"]
  

  执行创建命令：

  kubectl apply -f <上述Role文件路径> -n test-namespace
  

  再绑定到Notebook的服务账号：

  kubectl create rolebinding kserve-access-binding -n test-namespace \
    --role=kserve-inference-access \
    --serviceaccount=test-namespace:<获取到的服务账号名称>
  

2. Istio认证策略拦截请求 #

KServe 0.9.0配合Kubeflow 1.6.0通常会启用Istio的认证策略，若请求未携带有效凭证会被拦截。

• 在Notebook请求中添加认证令牌：
  修改你的Python代码，读取Pod内的服务账号令牌并添加到请求头：

  import requests
  from kubernetes import config
  
  config.load_incluster_config()
  # 读取服务账号令牌
  with open('/var/run/secrets/kubernetes.io/serviceaccount/token', 'r') as f:
      auth_token = f.read()
  
  headers = {
      'Authorization': f'Bearer {auth_token}',
      'Content-Type': 'application/json'
  }
  
  # 发送请求示例
  inference_url = "<你的InferenceService地址>"
  payload = {"inputs": [{"name": "input", "shape": [1, 28, 28], "datatype": "FP32", "data": [0.1]*784}]}
  response = requests.post(inference_url, json=payload, headers=headers)
  print(response.text)
  

3. Profile命名空间权限配置不完整 #

通过Profile创建命名空间时，可能未自动配置KServe相关的RBAC规则。

• 修改Profile添加KServe权限：
  更新你的profile.yaml，添加RBAC规则：

  apiVersion: kubeflow.org/v1
  kind: Profile
  metadata:
    name: test-namespace
  spec:
    owner:
      kind: User
      name: <你的用户名>
    rbac:
      rules:
      - apiGroups: ["serving.kserve.io"]
        resources: ["inferenceservices"]
        verbs: ["get", "list", "watch", "create", "update"]
  

  重新应用Profile：

  kubectl apply -f profile.yaml
  

4. 主节点调度后的Sidecar或权限异常 #

虽然取消了主节点污点，但Pod调度到主节点后可能存在Istio Sidecar注入异常或权限继承问题。

• 检查并启用主节点Istio注入：

  kubectl label nodes <主节点名称> istio-injection=enabled --overwrite
  

• 重启Notebook Pod：

  kubectl delete pod <你的Notebook Pod名称> -n test-namespace
  

  等待Pod重建后，重新尝试调用模型。

内容的提问来源于stack exchange，提问作者TaeUk Noh