Kubernetes Role-Based Access Control(RBAC)
Controle de Acesso Baseado em Função (RBAC)
O Kubernetes possui um módulo de autorização chamado Controle de Acesso Baseado em Função (RBAC) que ajuda a definir permissões de utilização para o servidor de API.
O modelo de permissão do RBAC é construído a partir de três partes individuais:
Sujeito (Usuário, Grupo ou ServiceAccount) – O objeto que receberá as permissões.
RoleBinding/ClusterRoleBinding – A conexão entre Função/ClusterRole e o sujeito.
A diferença entre "Funções" e "ClusterRoles" está apenas onde a função será aplicada – uma "Função" concederá acesso a apenas um namespace específico, enquanto um "ClusterRole" pode ser usado em todos os namespaces no cluster. Além disso, ClusterRoles também podem conceder acesso a:
recursos de escopo de cluster (como nós).
endpoints de não recurso (como /healthz).
recursos de namespace (como Pods), em todos os namespaces.
A partir do Kubernetes 1.6 em diante, as políticas de RBAC são ativadas por padrão. Mas para habilitar o RBAC, você pode usar algo como:
Modelos
No modelo de uma Função ou de um ClusterRole você precisará indicar o nome da função, o espaço de nomes (em funções) e então os apiGroups, recursos e verbos da função:
Os apiGroups são uma matriz que contém os diferentes espaços de nomes da API aos quais essa regra se aplica. Por exemplo, uma definição de Pod usa apiVersion: v1. Pode ter valores como rbac.authorization.k8s.io ou [*].
Os recursos são uma matriz que define a quais recursos essa regra se aplica. Você pode encontrar todos os recursos com:
kubectl api-resources --namespaced=true
Os verbos são uma matriz 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 de listagem é usado em coleções enquanto "get" é usado em um único recurso.
Verbos de Regras
(Essas informações foram retiradas da documentação)
Verbo HTTP | verbo da requisição |
---|---|
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) |
Às vezes o Kubernetes verifica a autorização para permissões adicionais usando verbos especializados. Por exemplo:
Verbo
use
em recursospodsecuritypolicies
no grupo de APIpolicy
.Verbos
bind
eescalate
em recursosroles
eclusterroles
no grupo de APIrbac.authorization.k8s.io
.Verbo
impersonate
emusuários
,grupos
econtas de serviço
no grupo de API principal, e osuserextras
no grupo de APIauthentication.k8s.io
.
Você pode encontrar todos os verbos que cada recurso suporta executando kubectl api-resources --sort-by name -o wide
Exemplos
Por exemplo, você pode usar um ClusterRole para permitir que um usuário específico execute:
RoleBinding e ClusterRoleBinding
Da documentação: Um role binding concede as permissões definidas em um role para um usuário ou conjunto de usuários. Ele contém uma lista de subjects (usuários, grupos ou contas de serviço) e uma referência ao role 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 "list" e "delete" de segredos, você pode adicioná-lo com um Role com "get". Portanto, esteja ciente e teste sempre seus papéis e permissões e especifique o que é PERMITIDO, pois por padrão tudo é NEGADO.
Enumerando RBAC
Abuso de Funções/ClusterRoles para Escalação de Privilégios
Abusing Roles/ClusterRoles in KubernetesLast updated