Kubernetes: Os volumes persistentes RBAC não funcionam com namespaces

Criado em 19 dez. 2016  ·  3Comentários  ·  Fonte: kubernetes/kubernetes

RELATÓRIO DE ERRO

Versão do Kubernetes (use kubectl version ): Versão do cliente: version.Info {Principal: "1", Secundária: "5", GitVersion: "v1.5.1", GitCommit: "82450d03cb057bab0950214ef122b67c83fb11df", GitTreeState: "clean" , BuildDate: "2016-12-14T00: 57: 05Z", GoVersion: "go1.7.4", Compilador: "gc", Plataforma: "darwin / amd64"}
Versão do servidor: version.Info {Principal: "1", Secundário: "5+", GitVersion: "v1.5.1-3 + 10e41f22e4421c", GitCommit: "10e41f22e4421c9a14e9e6782c6375c199a07a86", GitTree 2016-12State: "clean", -15T10: 06: 44Z ", GoVersion:" go1.7.4 ", Compilador:" gc ", Plataforma:" linux / amd64 "}

Meio Ambiente :

  • Provedor de nuvem ou configuração de hardware : openstack
  • SO (por exemplo, de / etc / os-release): centos7
  • Kernel (por exemplo, uname -a ): 3.10.0-327.36.3.el7.x86_64

O que aconteceu : habilitamos a autenticação RBAC. Temos duas amarras diferentes:

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

e

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

Portanto, temos dois usuários diferentes: clusteradmin, que tem acesso a tudo no cluster kube e defaultadmin, que deve ter acesso a todos os recursos no namespace padrão. Executar comandos PV com clusteradmin funciona bem, ao usar defaultadmin no namespace padrão, ocorre o erro:

kubectl get pv
Erro do servidor (Proibido): o servidor não permite acesso ao recurso solicitado (obter volumes persistentes)

Erro do servidor (Proibido): erro ao criar "db-pv.yaml": o servidor não permite o acesso ao recurso solicitado (post persistentvolumes)

O que você esperava que acontecesse : defaultadmin deve ter acesso aos recursos PV no namespace definido (no meu caso, o padrão), porque cluster-admin clusterrole diz o seguinte:

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

O importante aqui são os recursos *, mas parece que o PV não faz parte do curinga.

Como reproduzi-lo (o mínimo e precisamente possível):

  • habilitar RBAC
  • criar dois usuários, clusteradmin e defaultadmin
  • adicione clusterrolebinding e rolebinding que foi mencionado anteriormente neste tíquete de bug
  • execute comandos PV no namespace padrão com ambos os usuários

Comentários muito úteis

PVs são objetos com escopo de cluster. Eles não existem em um namespace. Para obter permissão para usar a API PV com RBAC, você precisa de um ClusterRole vinculado ao escopo do cluster com um ClusterRoleBinding .

Todos 3 comentários

Estou tendo um problema semelhante, em que alguns namespaces incluem dev e default . Como um "usuário dev", posso criar vários recursos no namespace dev , incluindo um PVC, mas criar o PV como o "usuário dev" no namespace dev resulta no mesmo erro como acima:

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

Posso criar o PV como o usuário administrador no namespace default , e então está tudo bem.

PVs não estão conectados a um namespace

PVs são objetos com escopo de cluster. Eles não existem em um namespace. Para obter permissão para usar a API PV com RBAC, você precisa de um ClusterRole vinculado ao escopo do cluster com um ClusterRoleBinding .

Esta página foi útil?
0 / 5 - 0 avaliações