K8s em Exemplos: RBAC

RBAC controla quem pode fazer o quê no cluster. Duas peças: uma Role define quais ações são permitidas em quais recursos, e um RoleBinding concede essa Role a usuários ou ServiceAccounts. Use ClusterRole e ClusterRoleBinding quando precisar de acesso cluster-wide.
role.yaml

Role define permissões dentro de um namespace. apiGroups especifica a qual grupo de API o recurso pertence: "" para recursos core (pods, services, configmaps), “apps” para deployments, “rbac.authorization.k8s.io” para roles. verbs são as ações permitidas.

 
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: default
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
rolebinding.yaml

RoleBinding concede uma Role a subjects (user, group, ou ServiceAccount) dentro de um namespace. A Role e RoleBinding devem estar no mesmo namespace. Pode ter múltiplos subjects.

 
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
  - kind: ServiceAccount
    name: my-app
    namespace: default
  - kind: User
    name: jane@example.com
    apiGroup: rbac.authorization.k8s.io
  - kind: Group
    name: developers
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
clusterrole.yaml

ClusterRole + ClusterRoleBinding para acesso cluster-wide. Use com moderação. Prefira roles com escopo de namespace. ClusterRoles também podem ser vinculadas a namespaces específicos via RoleBinding.

 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader
rules:
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get", "list"]
---
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
  - kind: ServiceAccount
    name: monitoring
    namespace: monitoring
roleRef:
  kind: ClusterRole
  name: secret-reader
---
kind: RoleBinding
metadata:
  name: read-secrets-in-default
  namespace: default
subjects:
  - kind: ServiceAccount
    name: my-app
    namespace: default
roleRef:
  kind: ClusterRole
  name: secret-reader
role-verbs.yaml

Verbs comuns: get, list, watch, create, update, patch, delete, deletecollection. Use * para todos os verbs (perigoso). Acesse subresources como pods/log, pods/exec separadamente.

 
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]

  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["*"]

  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]

  - apiGroups: [""]
    resources: ["pods/log", "pods/exec"]
    verbs: ["get", "create"]
role-resourcenames.yaml

Resource names restringem acesso a objetos específicos. Útil para conceder acesso a um ConfigMap ou Secret sem acesso a todos. Nota: resourceNames não se aplica a operações create/list.

 
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    resourceNames: ["my-app-config"]
    verbs: ["get", "update"]

  - apiGroups: ["apps"]
    resources: ["deployments"]
    resourceNames: ["my-app"]
    verbs: ["get", "update", "patch"]
clusterrole-aggregation.yaml

ClusterRoles agregadas combinam regras de múltiplas ClusterRoles. Roles built-in como admin, edit, view usam agregação. Adicione permissões criando ClusterRoles com labels correspondentes.

 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring
aggregationRule:
  clusterRoleSelectors:
    - matchLabels:
        rbac.example.com/aggregate-to-monitoring: "true"
rules: []
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring-pods
  labels:
    rbac.example.com/aggregate-to-monitoring: "true"
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
rolebinding-builtin.yaml

ClusterRoles built-in: cluster-admin (superuser), admin (admin de namespace), edit (leitura/escrita maioria dos recursos), view (somente leitura). Vincule estas para padrões de acesso comuns.

 
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: namespace-admin
  namespace: my-team
subjects:
  - kind: User
    name: alice@example.com
roleRef:
  kind: ClusterRole
  name: admin
  apiGroup: rbac.authorization.k8s.io
---
kind: RoleBinding
metadata:
  name: namespace-viewer
  namespace: my-team
subjects:
  - kind: Group
    name: contractors
roleRef:
  kind: ClusterRole
  name: view
terminal

Debug RBAC com kubectl auth can-i. Verifique permissões para você mesmo ou impersone outros usuários/ServiceAccounts. Liste todas as permissões para entender acesso efetivo.

 
$ kubectl auth can-i create pods
yes

$ kubectl auth can-i delete deployments -n production
no

$ kubectl auth can-i get secrets \
    --as=system:serviceaccount:default:my-app
no

$ kubectl auth can-i '*' '*' --as=jane@example.com
no

$ kubectl auth can-i --list
Resources                          Non-Resource URLs   Verbs
pods                               []                  [get list watch]
configmaps                         []                  [get list]
...

$ kubectl auth can-i --list \
    --as=system:serviceaccount:default:my-app

Índice | GitHub | Use as setas do teclado para navegar |