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 :
uname -a
): 3.10.0-327.36.3.el7.x86_64O 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):
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 .
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 .