Práticas recomendadas para o RBAC do GKE

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Nesta página, você verá práticas recomendadas para planejar suas políticas de controle de acesso baseado em papéis (RBAC, na sigla em inglês). Para saber como implementar o RBAC no Google Kubernetes Engine (GKE), consulte Configurar o controle de acesso baseado em papéis.

O RBAC é um recurso de segurança principal do Kubernetes, que permite criar permissões refinadas para gerenciar quais ações os usuários e cargas de trabalho podem executar nos recursos dos clusters. Como administrador de plataforma, você cria papéis do RBAC e vincula esses papéis a subjectores, que são usuários autenticados, como o serviço contas ou grupos.

Antes de começar

Verifique se você está familiarizado com os seguintes conceitos:

Para uma lista de verificação, consulte o Resumo da lista de verificação.

Como o RBAC funciona

O RBAC é compatível com os seguintes tipos de papéis e vinculações:

  • ClusterRole: conjunto de permissões aplicáveis a qualquer namespace ou a todo o cluster.
  • Papel: um conjunto de permissões limitado a um único namespace.
  • ClusterRoleBinding: atribua um ClusterRole a um usuário ou a um grupo para todos os namespaces no cluster.
  • RoleBinding: atribua um Role ou ClusterRole a um usuário ou grupo em um namespace específico.

Defina as permissões como rules em um Role ou uma ClusterRole. Cada campo rules em um papel consiste em um grupo de APIs, os recursos da API nesse grupo e os verbos (ações) permitidos nesses recursos. Também é possível definir o verbo para instâncias nomeadas de recursos da API usando o campo resourceNames. Para ver um exemplo, consulte Restringir o acesso a instâncias de recursos específicas.

Depois de definir um papel, use RoleBinding ou ClusterRoleBinding para vinculá-lo a um sujeito. Escolha o tipo de vinculação com base na concessão de permissões em um único namespace ou em vários namespaces.

Design de papéis do RBAC

Use o princípio de privilégio mínimo

Ao atribuir permissões em um papel do RBAC, use o princípio de privilégio mínimo e conceda o mínimo de permissões necessárias para executar uma tarefa. O uso do princípio de privilégio mínimo reduz o potencial de escalonamento de privilégios se o cluster estiver comprometido e reduz a probabilidade de que o acesso excessivo resulte em um incidente de segurança.

Ao projetar seus papéis, considere cuidadosamente os riscos comuns de escalonamento de privilégios, como verbos escalate ou bind, acesso create para PersistentVolumes ou acesso create para solicitações de assinatura de certificado. Para ver uma lista de riscos, consulte RBAC do Kubernetes: riscos de escalonamento de privilégios.

Evitar funções e grupos padrão

O Kubernetes cria automaticamente um conjunto de objetos ClusterRole e ClusterRoleBinding, que pode ser usado para descoberta de APIs e para ativar a funcionalidade de componentes gerenciados. As permissões concedidas por esses papéis padrão podem ser extensas. Por exemplo, o ClusterRole cluster-admin concede a um sujeito permissão para fazer qualquer coisa em qualquer recurso. Se você vincular o ClusterRole cluster-admin a um usuário ou conta de serviço usando um ClusterRoleBinding, esse assunto terá capacidade ilimitada no cluster.

Antes de vincular um papel padrão a um assunto, avalie as permissões concedidas por esse papel em relação ao seu caso de uso. Esteja ciente do risco. Para ver uma lista completa dos papéis e vinculações padrão que o Kubernetes cria, consulte Papéis e vinculações de papéis padrão.

O Kubernetes também cria grupos padrão vinculados aos papéis padrão. Por exemplo, o ClusterRole cluster-admin está vinculado ao grupo system:masters para fornecer componentes gerenciados ao acesso total ao servidor da API. Evite adicionar seus próprios assuntos ao system:masters.

Quando possível, use as seguintes diretrizes:

  • Não adicione seus próprios assuntos ao grupo system:masters.
  • Não vincule o grupo system:unauthenticated a nenhum papel do RBAC.
  • Não vincule o ClusterRole cluster-admin aos seus próprios sujeitos.
  • Avalie as permissões concedidas por outros papéis padrão antes de vincular assuntos.
  • Avalie os papéis vinculados aos grupos padrão antes de modificar os membros deles.

Permissões do escopo para o nível de namespace

Use vinculações e papéis da seguinte maneira, dependendo das necessidades da carga de trabalho ou do usuário:

  • Para conceder acesso a recursos em um namespace, use um Role com um RoleBinding.
  • Para conceder acesso a recursos em mais de um namespace, use um ClusterRole com um RoleBinding para cada namespace.
  • Para conceder acesso a recursos em todos os namespaces, use um ClusterRole com um ClusterRoleBinding.

Conceda permissões no menor número possível de namespaces.

Não use caracteres curinga

O caractere * é um padrão de caracteres curinga que se aplica a tudo. Evite usar caracteres curinga nas regras. Especificar explicitamente grupos de API, recursos e verbos nas regras do RBAC Por exemplo, a especificação de * no campo verbs concederia get, list, watch, patch, update, deletecollection, e delete nos recursos. A tabela a seguir mostra exemplos de como evitar caracteres curinga nas regras:

Recomendado Não recomendado

- rules:
    apiGroups: ["apps","extensions"]
    resources: ["deployments"]
    verbs: ["get","list","watch"]

Concede verbos get, list e watch especificamente aos grupos de APIs apps e extensions.


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

Concede os verbos a deployments em qualquer grupo de APIs.


- rules:
    apiGroups: ["apps", "extensions"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch"]

Concede apenas verbos get, list e watch às implantações nos grupos de APIs apps e extensions.


- rules:
    apiGroups: ["apps", "extensions"]
    resources: ["deployments"]
    verbs: ["*"]

Concede todos os verbos, incluindo patch ou delete.

Use regras separadas para conceder acesso com privilégio mínimo a recursos específicos

Ao planejar suas regras, tente as seguintes etapas gerais para um design de regra de privilégio mínimo mais eficiente em cada papel:

  1. Rascunho de regras separadas do RBAC para cada verbo em cada recurso que um assunto precisa acessar.
  2. Depois de fazer o rascunho das regras, analise-as para verificar se várias têm a mesma lista verbs. Combine essas regras em uma única regra.
  3. Mantenha todas as regras restantes separadas.

Essa abordagem resulta em um design de regra mais organizado, em que as regras que concedem os mesmos verbos a vários recursos são combinadas e as regras que concedem verbos diferentes a recursos são separadas.

Por exemplo, se sua carga de trabalho precisar de permissões para o recurso deployments, mas precisar de list e watch nos recursos daemonsets, use regras separadas ao criar um papel. Quando você vincula o papel do RBAC à carga de trabalho, ele não pode usar watch em deployments.

Outro exemplo: se sua carga de trabalho precisa de get e watch nos recursos pods e daemonsets, é possível combiná-las em uma única regra, porque a carga de trabalho precisa dos mesmos verbos nos dois recursos.

Na tabela a seguir, os dois projetos de regras funcionam, mas as regras de divisão restringem mais o acesso a recursos com base nas suas necessidades:

Recomendado Não recomendado

- rules:
    apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get"]
- rules:
    apiGroups: ["apps"]
    resources: ["daemonsets"]
    verbs: ["list", "watch"]

Concede acesso de get para implantações e acesso de watch e list para DaemonSets. Assuntos não podem listar implantações.


- rules:
    apiGroups: ["apps"]
    resources: ["deployments", "daemonsets"]
    verbs: ["get","list","watch"]

Concede os verbos a implantações e DaemonSets. Um sujeito que não pode exigir acesso list em objetos deployments ainda receberia esse acesso.


- rules:
    apiGroups: ["apps"]
    resources: ["daemonsets", "deployments"]
    verbs: ["list", "watch"]

Combina duas regras porque o assunto precisa dos mesmos verbos para os recursos daemonsets e deployments.


- rules:
    apiGroups: ["apps"]
    resources: ["daemonsets"]
    verbs: ["list", "watch"]
- rules:
    apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["list", "watch"]

Essas regras de divisão teriam o mesmo resultado que a regra combinada, mas criariam desordem desnecessária no manifesto do papel.

Restringir o acesso a instâncias de recursos específicas

O RBAC permite usar o campo resourceNames nas suas regras para restringir o acesso a uma instância específica nomeada de um recurso. Por exemplo, se você estiver criando um papel de RBAC que precise update do ConfigMap seccomp-high e nada mais, use resourceNames para especificar apenas esse ConfigMap. Use resourceNames sempre que possível.

Recomendado Não recomendado

- rules:
    apiGroups: [""]
    resources: ["configmaps"]
    resourceNames: ["seccomp-high"]
    verbs: ["update"]

Restringe o assunto a atualizar apenas o ConfigMap seccomp-high. O assunto não pode atualizar nenhum outro ConfigMaps no namespace.


- rules:
    apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["update"]

O assunto pode atualizar o ConfigMap seccomp-high e qualquer outro ConfigMap no namespace.


- rules:
    apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["list"]
- rules:
    apiGroups: [""]
    resources: ["configmaps"]
    resourceNames: ["seccomp-high"]
    verbs: ["update"]

Concede acesso de list a todos os ConfigMaps no namespace, incluindo seccomp-high. Restringe o acesso update apenas ao ConfigMap seccomp-high. As regras são divididas porque não é possível conceder a list recursos nomeados.


- rules:
    apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["update", "list"]

Concede acesso de update para todos os ConfigMaps, além de acesso list.

Não permitir que as contas de serviço modifiquem recursos do RBAC

Não vincule recursos Role ou ClusterRole que tenham as permissões bind, escalate, create, update ou patch à rbac.authorization.k8s.io Grupo de APIs para contas de serviço em qualquer namespace. escalate e bind, em particular, podem permitir que um invasor ignore os mecanismos de prevenção de encaminhamento integrados ao RBAC.

Contas de Serviço Kubernetes

Crie uma conta de serviço do Kubernetes para cada carga de trabalho

Crie uma conta de serviço do Kubernetes separada para cada carga de trabalho. Vincule um privilégio mínimo Role ou ClusterRole a essa conta de serviço.

Não usar a conta de serviço padrão

O Kubernetes cria uma conta de serviço chamada default em todos os namespaces. A conta de serviço default é atribuída automaticamente aos pods que não especificam explicitamente uma conta de serviço no manifesto. Evite vincular um Role ou ClusterRole à conta de serviço default. O Kubernetes pode atribuir a conta de serviço default a um pod que não precisa do acesso concedido nesses papéis.

Não montar tokens de conta de serviço automaticamente

O campo automountServiceAccountToken na especificação do pod informa ao Kubernetes para injetar um token de credencial de uma conta de serviço do Kubernetes no pod. O pod pode usar esse token para fazer solicitações autenticadas para o servidor da API Kubernetes. O valor padrão deste campo é true.

Em todas as versões do GKE, defina automountServiceAccountToken=false na especificação do pod se os pods não precisarem se comunicar com o servidor da API.

Use tokens temporários em vez de tokens baseados em secrets

Ao criar e usar tokens de conta de serviço, evite usar secrets do Kubernetes para armazenar o token. Os tokens de conta de serviço baseados em secret são credenciais legadas que não expiram e não são alternadas automaticamente. Se você precisar de credenciais para contas de serviço, use a API TokenRequest para receber tokens de curta duração que são alternados automaticamente.

Analisar continuamente as permissões do RBAC

Revise os papéis do RBAC e o acesse regularmente para identificar possíveis caminhos de escalonamento e regras redundantes. Por exemplo, considere uma situação em que você não exclui uma RoleBinding que vincula um Role com privilégios especiais a um usuário excluído. Se um invasor criar uma conta de usuário nesse namespace com o mesmo nome do usuário excluído, ele será vinculado a esse Role e herdará o mesmo acesso. As avaliações periódicas minimizam esse risco.

Lista de verificação resumida

A seguir