我正在嘗試將kubectl auth can-i 邏輯合并到我的代碼庫中,但是當(dāng)代碼運(yùn)行時,結(jié)果不是我所期望的。我有 2 個用戶(minikube / jenny)。minikube具有完整的集群范圍訪問權(quán)限,但jenny僅限于命名空間角色/角色綁定:kubectl create role "jenny-pod-creator" --verb=create --resource=pod -n "jenny"kubectl create rolebinding "jenny-creator-binding" --role="jenny-pod-creator" --user="jenny" --namespace="jenny"使用 cli,我得到了我期望的結(jié)果:$ kubectl auth can-i create pod --context jenny -n jennyyes$ kubectl auth can-i create pod --context jenny -n defaultno - RBAC: role.rbac.authorization.k8s.io "jenny-pod-creator" not found但在我的代碼中,珍妮沒有提出創(chuàng)建權(quán)限。response.Status.Allowed始終false適用于jenny (對于minikube始終適用)package mainimport ( "context" "fmt" "log" "os" "path/filepath" authorizationv1 "k8s.io/api/authorization/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/client-go/kubernetes" "k8s.io/client-go/tools/clientcmd")func main() { kubeconfig := filepath.Join( os.Getenv("HOME"), ".kube", "config", ) config, err := clientcmd.BuildConfigFromFlags("", kubeconfig) if err != nil { log.Fatal(err) } clientset, err := kubernetes.NewForConfig(config) if err != nil { log.Fatal(err) } a := clientset.AuthorizationV1().SelfSubjectAccessReviews() sar := &authorizationv1.SelfSubjectAccessReview{ Spec: authorizationv1.SelfSubjectAccessReviewSpec{ ResourceAttributes: &authorizationv1.ResourceAttributes{ Namespace: "jenny", Verb: "create", Resource: "Pod", }, }, } response, err := a.Create(context.TODO(), sar, metav1.CreateOptions{}) if err != nil { log.Fatal(err) } fmt.Printf("create resource POD is %v \n", response.Status.Allowed)}
1 回答

不負(fù)相思意
TA貢獻(xiàn)1777條經(jīng)驗 獲得超10個贊
在 Kubernetes 中有一個種類和資源的概念。如果您想了解更多信息,請在 Kubernetes 對象和資源之間的區(qū)別和API 約定中很好地解釋它。
簡而言之:
Kind是告訴客戶端它代表什么樣的實(shí)體的類型,例如,它總是大寫
Pod
。Resource是通過 HTTP 發(fā)送的此類實(shí)體的表示形式,并且始終是小寫復(fù)數(shù)形式。
在您的情況下,您正在使用Resource,因此您需要將Pod
( Kind ) 更改為pods
( resource ),這應(yīng)該為您true
提供jenny
. 至于 minikube,你總是true
因為那個用戶是 system:admin,它擁有對集群的完全訪問權(quán)限。
- 1 回答
- 0 關(guān)注
- 153 瀏覽
添加回答
舉報
0/150
提交
取消