Kubernetes Role-Based Access Control(RBAC)
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Kubernetes tem 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ão do RBAC é construído a partir de três partes individuais:
Subject (Usuário, Grupo ou ServiceAccount) – O objeto que receberá as permissões.
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:
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.
(Esta informação foi retirada de the docs)
HTTP verb | request verb |
---|---|
POST | create |
GET, HEAD | get (para recursos individuais), list (para coleções, incluindo conteúdo completo do objeto), watch (para observar um recurso individual ou coleção de recursos) |
PUT | update |
PATCH | patch |
DELETE | delete (para recursos individuais), deletecollection (para coleções) |
O Kubernetes às vezes verifica a autorização para permissões adicionais usando verbos especializados. Por exemplo:
verbo use
em recursos podsecuritypolicies
no grupo de API policy
.
verbos bind
e escalate
em recursos roles
e clusterroles
no grupo de API rbac.authorization.k8s.io
.
verbo impersonate
em users
, groups
e serviceaccounts
no grupo de API core, e o userextras
no grupo de API authentication.k8s.io
.
Você pode encontrar todos os verbos que cada recurso suporta executando kubectl api-resources --sort-by name -o wide
Por exemplo, você pode usar um ClusterRole para permitir que um usuário específico execute:
Da documentação: Um role binding concede as permissões definidas em um papel 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 papel sendo concedido. Um RoleBinding concede permissões dentro de um namespace específico, enquanto um ClusterRoleBinding concede esse acesso em todo o cluster.
As permissões são aditivas, então se você tiver um clusterRole com “listar” e “deletar” segredos, você pode adicioná-lo a um Role com “obter”. Portanto, esteja ciente e sempre teste seus roles e permissões e especifique o que é PERMITIDO, porque tudo é NEGADO por padrão.
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)