Controle de Acesso Baseado em Funções (RBAC) do Kubernetes

Reading time: 6 minutes

Controle de Acesso Baseado em Funções (RBAC)

O Kubernetes possui um módulo de autorização chamado Controle de Acesso Baseado em Funções (RBAC) que ajuda a definir permissões de utilização para o servidor API.

O modelo de permissões do RBAC é construído a partir de três partes individuais:

1. Role\ClusterRole ­– A permissão real. Contém regras que representam um conjunto de permissões. Cada regra contém recursos e verbos. O verbo é a ação que será aplicada ao recurso.
2. Subject (Usuário, Grupo ou ServiceAccount) – O objeto que receberá as permissões.
3. RoleBinding\ClusterRoleBinding – A conexão entre Role\ClusterRole e o sujeito.

A diferença entre “Roles” e “ClusterRoles” é apenas onde a função será aplicada – uma “Role” concederá acesso a apenas um namespace específico, enquanto uma “ClusterRole” pode ser usada em todos os namespaces no cluster. Além disso, ClusterRoles também podem conceder acesso a:

• recursos escopados ao cluster (como nós).
• endpoints não-recurso (como /healthz).
• recursos namespaced (como Pods), em todos os namespaces.

A partir do Kubernetes 1.6, as políticas de RBAC estão ativadas por padrão. Mas para ativar o RBAC, você pode usar algo como:

kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options

Templates

No template de um Role ou um ClusterRole, você precisará indicar o nome do papel, o namespace (em roles) e então os apiGroups, resources e verbs do papel:

• Os apiGroups são um array que contém os diferentes namespaces de API aos quais esta regra se aplica. Por exemplo, uma definição de Pod usa apiVersion: v1. Pode ter valores como rbac.authorization.k8s.io ou [*].
• Os resources são um array que define quais recursos esta regra se aplica. Você pode encontrar todos os recursos com: kubectl api-resources --namespaced=true
• Os verbs são um array que contém os verbos permitidos. O verbo no Kubernetes define o tipo de ação que você precisa aplicar ao recurso. Por exemplo, o verbo list é usado contra coleções, enquanto "get" é usado contra um único recurso.

Rules Verbs

(Esta informação foi retirada de the docs)

O Kubernetes às vezes verifica a autorização para permissões adicionais usando verbos especializados. Por exemplo:

• PodSecurityPolicy
• verbo use em recursos podsecuritypolicies no grupo de API policy.
• RBAC
• verbos bind e escalate em recursos roles e clusterroles no grupo de API rbac.authorization.k8s.io.
• Authentication
• verbo impersonate em users, groups e serviceaccounts no grupo de API core, e o userextras no grupo de API authentication.k8s.io.

Examples

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: defaultGreen
name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
# "namespace" omitted since ClusterRoles are not namespaced
name: secret-reader
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]

Por exemplo, você pode usar um ClusterRole para permitir que um usuário específico execute:

kubectl get pods --all-namespaces

RoleBinding e ClusterRoleBinding

Da documentação: Um role binding concede as permissões definidas em um role a um usuário ou conjunto de usuários. Ele contém uma lista de sujeitos (usuários, grupos ou contas de serviço) e uma referência ao role sendo concedido. Um RoleBinding concede permissões dentro de um namespace específico, enquanto um ClusterRoleBinding concede esse acesso em todo o cluster.

piVersion: rbac.authorization.k8s.io/v1
# This role binding allows "jane" to read pods in the "default" namespace.
# You need to already have a Role named "pod-reader" in that namespace.
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
# You can specify more than one "subject"
- kind: User
name: jane # "name" is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
# "roleRef" specifies the binding to a Role / ClusterRole
kind: Role #this must be Role or ClusterRole
name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
apiGroup: rbac.authorization.k8s.io

apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
metadata:
name: read-secrets-global
subjects:
- kind: Group
name: manager # Name is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io

As permissões são aditivas então se você tem um clusterRole com “listar” e “deletar” segredos, você pode adicioná-lo a um Role com “obter”. Portanto, esteja ciente e sempre teste seus papéis e permissões e especifique o que é PERMITIDO, porque tudo é NEGADO por padrão.

Enumerando RBAC

# Get current privileges
kubectl auth can-i --list
# use `--as=system:serviceaccount:<namespace>:<sa_name>` to impersonate a service account

# List Cluster Roles
kubectl get clusterroles
kubectl describe clusterroles

# List Cluster Roles Bindings
kubectl get clusterrolebindings
kubectl describe clusterrolebindings

# List Roles
kubectl get roles
kubectl describe roles

# List Roles Bindings
kubectl get rolebindings
kubectl describe rolebindings

Abusar de Roles/ClusterRoles para Escalação de Privilégios

Abusing Roles/ClusterRoles in Kubernetes