Skip to main content

RBAC

Já foi estudado antes no CKA. Vamos apenas colocar a diferença encontrada para o CKS.

Recomendo a leitura:

O controle de acesso baseado em função é um método de regular o acesso a recursos de computador ou rede com base nas funções de usuários individuais dentro de sua organização.

O Kubernetes possui desde as primeiras versões e é utilizado até hoje.

Bloco de código do kube-apiserver.yaml

spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=10.128.0.5
    - --allow-privileged=true
    - --authorization-mode=Node,RBAC #<<<<
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    - --enable-admission-plugins=NodeRestriction
  • Restringe o acesso a recursos quando acessado por usuários ou service accounts.
  • Utiliza Role e Bindings
  • Só especifica o que é PERMITIDO, qualquer outra coisa é negada.
  • Não existe regra de negação.

Respeita o princípio do menor privilégio que é algo que temos que ter em mente toda vez que damos acessos.

Somente acessar dados ou informações necessárias para o propósito legítimo.

Entenda o que é um recurso a nível de namespace e a nível de cluster. Pode pegar uma leitura direto de api.

# Mostra os que recursos que são níveis de namespace
kubectl api-resources --namespace=true

# Nível de cluster
kubectl api-resources --namespace=false

# role e rolebindings estão em nível de namespace
# clusterrole e clusterrolebindings estão em nível de cluster
clusterrolebindings                              rbac.authorization.k8s.io/v1        false        ClusterRoleBinding
clusterroles                                     rbac.authorization.k8s.io/v1        false        ClusterRole
rolebindings                                     rbac.authorization.k8s.io/v1        true         RoleBinding
roles                                            rbac.authorization.k8s.io/v1        true         Role
  • os Bindings são para definir quem pode atuar com roles e clusterroles.
  • Roles são conjuntos de permissões que desempenham um papel.

Uma role que está em nível de namespace definirá permissões para um namespace.

Um clusterrole que está em nível de cluster definirá permissões em nível de todos os namespaces e de recursos fora do escopo de namespace, como por exemplo persistent volumes, nodes, etc.

Devemos ter cuidado com cluster roles pois qualquer novo namespace criado entrará nas permissões do cluster role.

alt text.

Uma role pode ser definida com o mesmo nome em vários diferentes namespaces.

alt text

Isso não significa que um user ou service account que atuará com uma role de nome secret-manager que tem permissão no namespace blue também terá no red. É necessário fazer o binding com ambos os namespaces. Os bindings é o que liga uma role com um user ou service account.

Cluster roles não possuem namespaces em sua definição, mas as permissões são as mesmas em todos os namespaces.

Podemos ter as seguintes combinações:

  • role + rolebinding (totalmente nível de namespace)
  • clusterrole + clusterrolebinding (nível de cluster)
  • clusterrole + rolebinding (limita os namespaces de ação da clusterrole)
  • role + clusterrolebinding (NÃO É POSSÍVEL)

    • NÃO PODEMOS CONVERTER ALGO DE NÍVEL DE NAMESPACE PARA NÍVEL DE CLUSTER.

Se dermos essas permissões para um usuário elas serão somadas.

alt text

Sempre teste as permissões com o kubectl auth can-i.

root@cks-master:/etc/kubernetes/manifests# k create namespace red
namespace/red created
root@cks-master:/etc/kubernetes/manifests# k create namespace blue
namespace/blue created
root@cks-master:/etc/kubernetes/manifests# k create role  -n red secret-manager --verb get --resource secrets
role.rbac.authorization.k8s.io/secret-manager created
root@cks-master:/etc/kubernetes/manifests# k create rolebinding -n red secret-manager --role=secret-manager --user=jane
rolebinding.rbac.authorization.k8s.io/secret-manager created
root@cks-master:/etc/kubernetes/manifests# k create role  -n blue secret-manager --verb=get,list --resource secrets
role.rbac.authorization.k8s.io/secret-manager created
root@cks-master:/etc/kubernetes/manifests# k create rolebinding -n blue secret-manager --role=secret-manager --user=jane
rolebinding.rbac.authorization.k8s.io/secret-manager created
root@cks-master:/etc/kubernetes/manifests# k -n red auth can-i get secrets --as jane
yes
root@cks-master:/etc/kubernetes/manifests# k -n red auth can-i get secrets --as john
no
root@cks-master:/etc/kubernetes/manifests# k -n red auth can-i list secrets --as jane
no
root@cks-master:/etc/kubernetes/manifests# k -n red auth can-i list pods --as jane
no
root@cks-master:/etc/kubernetes/manifests# k -n blue auth can-i list secrets --as jane
yes
root@cks-master:/etc/kubernetes/manifests# k -n blue auth can-i get secrets --as jane
yes
root@cks-master:/etc/kubernetes/manifests# k create clusterrole deploy-deleter --verb=delete --resource=deployments
clusterrole.rbac.authorization.k8s.io/deploy-deleter created
root@cks-master:/etc/kubernetes/manifests# k create clusterrolebinding deploy-deleter --user jane --clusterrole deploy-deleter
clusterrolebinding.rbac.authorization.k8s.io/deploy-deleter created
root@cks-master:/etc/kubernetes/manifests# k -n red create rolebinding deploy-deleter --user jim --clusterrole deploy-deleter
rolebinding.rbac.authorization.k8s.io/deploy-deleter created
root@cks-master:/etc/kubernetes/manifests# k auth can-i delete deployment --as jane
yes
root@cks-master:/etc/kubernetes/manifests# k -n red auth can-i delete deployment --as jane
yes
root@cks-master:/etc/kubernetes/manifests# k auth can-i delete deployment --as jim
no
root@cks-master:/etc/kubernetes/manifests# k auth can-i delete deployment --as jim -A
no
root@cks-master:/etc/kubernetes/manifests# k auth can-i delete deployment --as jim -n red
yes
root@cks-master:/etc/kubernetes/manifests# k auth can-i create deployment --as jane -n red
no
root@cks-master:/etc/kubernetes/manifests# k auth can-i create deployment --as jane
no
root@cks-master:/etc/kubernetes/manifests# k auth can-i create deployment --as jim -n red
no