Kubernetes Role-Based Access Control(RBAC)

Aprenda e pratique Hacking na AWS: HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking no GCP: HackTricks Training GCP Red Team Expert (GRTE)

Suporte ao HackTricks

• Verifique os planos de assinatura!

• Junte-se ao 💬 grupo Discord ou ao grupo telegram ou siga-nos no Twitter 🐦 @hacktricks_live.

• Compartilhe truques de hacking enviando PRs para os repositórios HackTricks e HackTricks Cloud.

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:

1. Função/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. Sujeito (Usuário, Grupo ou ServiceAccount) – O objeto que receberá as permissões.

3. 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:

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

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:

• Política de Segurança do Pod

• 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.

• Autenticação

• Verbo impersonate em usuários, grupos e contas de serviço no grupo de API principal, e os 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

Exemplos

Função

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"]

ClusterRole

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 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.

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

ClusterRoleBinding

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ê 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

# 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

Abuso de Funções/ClusterRoles para Escalação de Privilégios

Abusing Roles/ClusterRoles in Kubernetes

Aprenda e pratique Hacking na AWS: Treinamento HackTricks AWS Red Team Expert (ARTE) Aprenda e pratique Hacking no GCP: Treinamento HackTricks GCP Red Team Expert (GRTE)

Suporte ao HackTricks

• Verifique os planos de assinatura!

• Junte-se ao 💬 grupo Discord ou ao grupo telegram ou siga-nos no Twitter 🐦 @hacktricks_live.

• Compartilhe truques de hacking enviando PRs para os repositórios HackTricks e HackTricks Cloud.