Início / server / Perguntas / 1167831
Accepted
Sagar
Asked: 2024-11-16 00:30:50 +0800 CST

Por que o usuário pode "obter" segredos, dada a seguinte combinação de clusterrole/função?

  • 772

Tenho os seguintes ClusterRoles definidos:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: deployer-system
rules:
- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - list
- nonResourceURLs:
  - '*'
  verbs:
  - list

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: deployer-nonsystem
rules:
- apiGroups:
  - '*'
  resources:
  - secrets
  - PersistentVolumes
  - Role
  - RoleBinding
  verbs:
  - list
- apiGroups:
  - '*'
  resources:
  - deployments
  - pods
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
- nonResourceURLs:
  - '*'
  verbs:
  - list

Eu uso os seguintes RoleBindings para atribuir a um usuário o ClusterRole acima:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: theuser-nonsystem-role-binding
  namespace: nonsystem-namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: deployer-nonsystem
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: theuser

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: theuser-kube-system-role-binding
  namespace: system-namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: deployer-system
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: theuser

No entanto, eles conseguem executar um kubectl -n [NAMESPACE] get secrets -o yamle ver todos os segredos. Eu esperaria que essa chamada fosse proibida com base nas especificações ClusterRole acima.

Estou esquecendo ou entendendo mal alguma coisa aqui? Por que o usuário pode "pegar" segredos?

ATUALIZAÇÃO: Observe: meu problema NÃO é que eles podem listar segredos. Meu problema aqui é que o usuário pode "obter" segredos (verbos diferentes!)

kubernetes

1 respostas

  1. Best Answer

    Estou esquecendo ou entendendo mal alguma coisa aqui? Por que o usuário pode "pegar" segredos?

    Porque os listverbos significam " getaplicados a múltiplos recursos". Quando você executa a kubectl get secretoperação sem especificar um segredo individual, você está executando uma listoperação.

    Considerando o RBAC em sua pergunta, posso perguntar sobre todos os segredos no system-namespacenamespace:

    $ kubectl -n system-namespace get secret
NAME      TYPE     DATA   AGE
secret1   Opaque   1      2m54s

    Mas não posso pedir um segredo específico :

    $ kubectl -n system-namespace get secret secret1
Error from server (Forbidden): secrets "secret1" is forbidden: User "lars" cannot get resource "secrets" in API group "" in the namespace "system-namespace"

    Você deve pensar em listcomo uma versão mais poderosa de get, já que permite a alguém a capacidade de enumerar e recuperar todos os segredos. Com apenas getpermissão, uma entidade deve saber o nome de um segredo específico para acessá-lo, e você pode, de fato, restringir geto acesso a recursos específicos definindo o resourceNamescomponente de uma regra.

    Supondo que system-namespacetenha segredos secret1e secret2, se eu tiver uma conta vinculada à seguinte função:

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: deployer-system
rules:
- apiGroups:
  - ''
  resourceNames:
  - secret1
  resources:
  - secrets
  verbs:
  - get

    Então só posso recuperar o segredo secret1:

    $ kubectl get secret secret1
NAME      TYPE     DATA   AGE
secret1   Opaque   1      10m
$ kubectl get secret secret2
Error from server (Forbidden): secrets "secret2" is forbidden: User "lars" cannot get resource "secrets" in API group "" in the namespace "system-namespace"
    • 1

relate perguntas