Como o RBAC funciona com ServiceAccounts, e como você protege um cluster Kubernetes?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** governa *quem pode fazer o quê* na API. Permissões são concedidas a **subjects** (usuários, grupos, **ServiceAccounts**) fazendo **binding** deles a **Roles** que listam os verbs permitidos sobre recursos. O RBAC é uma camada de uma estratégia mais ampla de hardening do cluster.

## O modelo RBAC

```text
SUBJECT (usuário / grupo / ServiceAccount)
   │  vinculado por
   ▼
RoleBinding ───────► Role         (com namespace: permissões dentro de UM namespace)
ClusterRoleBinding ► ClusterRole  (a nível de cluster, ou reutilizável entre namespaces)

Role/ClusterRole = um conjunto de RULES: "estes VERBS sobre estes RESOURCES"
Os bindings são ADITIVOS e NÃO há deny — você concede apenas o que é necessário.
```

## Exemplo de Role + RoleBinding

```yaml
# Uma Role: acesso somente-leitura a Pods no namespace "app"
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: app
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
---
# Faz o bind dessa Role a uma ServiceAccount
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: app
  name: read-pods
subjects:
  - kind: ServiceAccount
    name: my-app
    namespace: app
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
```

## ServiceAccounts: identidade para Pods

```text
Uma ServiceAccount é a IDENTIDADE que um Pod usa para falar com o API server.
  → Todo Pod recebe uma (a SA "default" do namespace se não especificada).
  → Um token projetado é montado no Pod; o RBAC decide o que esse token pode fazer.
Boa prática: dê a cada workload sua PRÓPRIA SA com RBAC de menor privilégio,
e defina automountServiceAccountToken: false quando o Pod não precisa de acesso à API.
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # desative se nenhuma chamada à API for necessária
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # roda os Pods sob esta identidade
```

## Defesa em profundidade — além do RBAC

```text
AUTH        → RBAC de menor privilégio; ServiceAccounts por workload; auditoria de acesso
NETWORK     → NetworkPolicies default-deny (Pods não conversam a menos que permitido)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, drop de capabilities
              perfis seccomp; Pod Security Admission (restricted) para impor
SECRETS     → encryption at rest para o etcd; gerenciadores de secrets externos; RBAC restrito em secrets
IMAGES      → escaneie imagens, use registries confiáveis, imponha via admission (ex.: policy engines)
API/etcd    → restrinja & criptografe o etcd; TLS em todo lugar; limite acesso anônimo & cluster-admin
SUPPLY CHAIN→ imagens assinadas, admission control (OPA/Gatekeeper, Kyverno)
```

```bash
kubectl auth can-i list pods --as=system:serviceaccount:app:my-app -n app
kubectl auth can-i --list -n app          # o que o usuário atual pode fazer?
```

## Por que isso importa

Proteger um cluster é uma responsabilidade sênior, e o RBAC com ServiceAccounts é sua base, então entender ambos é conhecimento essencial de segurança. O modelo RBAC é elegante e vale a pena internalizá-lo: as permissões são **puramente aditivas, sem deny**, concedidas fazendo **binding de subjects** (usuários, grupos e especialmente **ServiceAccounts**) a **Roles** (com namespace) ou **ClusterRoles** (a nível de cluster) que enumeram os **verbs permitidos sobre recursos** — o que significa que boa segurança vem de conceder apenas o que cada workload precisa (**menor privilégio**) em vez de depender de negações. Entender que uma **ServiceAccount é a identidade que um Pod usa para chamar a API** — que todo Pod recebe um token, que a SA `default` é uma armadilha comum de excesso de privilégio, e que você deveria dar a cada workload sua própria SA de menor privilégio (e desabilitar o automount do token quando nenhum acesso à API é necessário) — é diretamente prático e uma fonte frequente de má configuração no mundo real. Crucialmente, um engenheiro sênior sabe que o RBAC é apenas uma camada da **defesa em profundidade**: **NetworkPolicies** default-deny, configurações de **securityContext** endurecidas (non-root, root filesystem somente-leitura, capabilities removidas, seccomp), **Pod Security Admission**, **encryption at rest** e gerenciadores externos para Secrets, escaneamento e assinatura de imagens, admission controllers (OPA/Gatekeeper, Kyverno) e acesso ao etcd/API bloqueado — tudo se combina para proteger um cluster. Como um cluster Kubernetes é um alvo de alto valor onde uma única ServiceAccount com privilégio excessivo ou uma NetworkPolicy aberta pode levar ao comprometimento total, dominar o RBAC e o conjunto mais amplo de ferramentas de hardening é fundamental para operar clusters com segurança em produção.

O modelo RBAC

Exemplo de Role + RoleBinding

ServiceAccounts: identidade para Pods

Defesa em profundidade — além do RBAC

Por que isso importa

Perguntas relacionadas