Kubernetes: Les volumes persistants RBAC ne fonctionnent pas avec les espaces de noms

Créé le 19 déc. 2016  ·  3Commentaires  ·  Source: kubernetes/kubernetes

RAPPORT D'ERREUR

Version Kubernetes (utilisez kubectl version ) : Version du client : version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.1", GitCommit:"82450d03cb057bab0950214ef122b67c83fb11df", GitTreeState:"clean" , BuildDate:"2016-12-14T00:57:05Z", GoVersion:"go1.7.4", Compilateur:"gc", Plateforme:"darwin/amd64"}
Version du serveur : version.Info{Major:"1", Minor :"5+", GitVersion:"v1.5.1-3+10e41f22e4421c", GitCommit:"10e41f22e4421c9a14e9e6782c6375c199a07a86", GitTreeState:"clean", BuildDate:"2016-12 -15T10:06:44Z", GoVersion:"go1.7.4", Compilateur:"gc", Plate-forme:"linux/amd64"}

Environnement :

  • Fournisseur cloud ou configuration matérielle : openstack
  • OS (par exemple depuis /etc/os-release) : centos7
  • Noyau (par exemple uname -a ): 3.10.0-327.36.3.el7.x86_64

Ce qui s'est passé : Nous avons activé l'authentification RBAC. Nous avons deux liaisons de rôle différentes :

apiVersion: rbac.authorization.k8s.io/v1alpha1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-custom
subjects:
- kind: ServiceAccount
  name: default
  namespace: kube-system
- kind: User
  name: kubelet
  namespace: kube-system
- kind: User
  name: clusteradmin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin

et

apiVersion: rbac.authorization.k8s.io/v1alpha1
kind: RoleBinding
metadata:
  name: default-admin
  namespace: default
subjects:
- kind: ServiceAccount
  name: default
- kind: User
  name: defaultadmin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin

Nous avons donc deux utilisateurs différents : clusteradmin, qui a accès à tout dans le cluster kube et defaultadmin, qui devrait avoir accès à toutes les ressources dans l'espace de noms par défaut. L'exécution de commandes PV avec clusteradmin fonctionne bien, lorsque vous utilisez defaultadmin dans l'espace de noms par défaut, cela génère une erreur :

kubectl obtenir pv
Erreur du serveur (Interdit) : le serveur n'autorise pas l'accès à la ressource demandée (obtenir des volumes persistants)

Erreur du serveur (Interdit) : erreur lors de la création de "db-pv.yaml" : le serveur n'autorise pas l'accès à la ressource demandée (post persistentvolumes)

Ce à quoi vous vous attendiez : defaultadmin devrait avoir accès aux ressources PV dans l'espace de noms défini (dans mon cas par défaut), car cluster-admin clusterrole dit ce qui suit :

- apiGroups:
  - '*'
  attributeRestrictions: null
  resources:
  - '*'
  verbs:
  - '*'
- attributeRestrictions: null
  nonResourceURLs:
  - '*'
  verbs:
  - '*'

L'important ici, ce sont les ressources *, mais il semble que PV ne fasse pas partie du caractère générique.

Comment le reproduire (le plus minimement et le plus précisément possible) :

  • activer RBAC
  • créer deux utilisateurs, clusteradmin et defaultadmin
  • ajouter clusterrolebinding et rolebinding qui a été mentionné précédemment dans ce ticket de bogue
  • exécuter les commandes PV dans l'espace de noms par défaut avec les deux utilisateurs

Commentaire le plus utile

Les PV sont des objets à portée de cluster. Ils n'existent pas dans un espace de noms. Pour obtenir l'autorisation d'utiliser l'API PV avec RBAC, vous avez besoin d'un ClusterRole lié à la portée du cluster avec un ClusterRoleBinding .

Tous les 3 commentaires

J'ai un problème similaire, où j'ai quelques espaces de noms, y compris dev et default . En tant qu'"utilisateur dev", je peux créer un tas de ressources dans l'espace dev noms dev noms

Error from server (Forbidden): error when creating "db-pv.yaml": the server does not allow access to the requested resource (post persistentvolumes)

Je peux créer le PV en tant qu'utilisateur administrateur dans l'espace default noms

Les PV ne sont pas connectés à un espace de noms

Les PV sont des objets à portée de cluster. Ils n'existent pas dans un espace de noms. Pour obtenir l'autorisation d'utiliser l'API PV avec RBAC, vous avez besoin d'un ClusterRole lié à la portée du cluster avec un ClusterRoleBinding .

Cette page vous a été utile?
0 / 5 - 0 notes