Kubernetes Role-Based Access Control(RBAC)

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

Suporte ao HackTricks

• Confira os planos de assinatura!

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

• Compartilhe truques de hacking enviando PRs para o HackTricks e HackTricks Cloud repositórios do github.

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ão 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 da função, o namespace (em roles) e então os apiGroups, resources e verbs da função:

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

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:

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

Você pode encontrar todos os verbos que cada recurso suporta executando kubectl api-resources --sort-by name -o wide

Examples

Role

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

Dos documentos: 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.

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

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

Support HackTricks

• Confira os planos de assinatura!

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

• Compartilhe truques de hacking enviando PRs para o HackTricks e HackTricks Cloud repositórios do github.