Práticas recomendadas para o RBAC do GKE

Esta página apresenta práticas recomendadas para planear as suas políticas de controlo de acesso baseado em funções (CABF). Para saber como implementar o RBAC no Google Kubernetes Engine (GKE), consulte o artigo Configure o controlo de acesso baseado em funções. O RBAC é uma funcionalidade de segurança essencial no Kubernetes que lhe permite criar autorizações detalhadas para gerir as ações que os utilizadores e as cargas de trabalho podem realizar nos recursos nos seus clusters. Cria funções RBAC e associa essas funções a sujeitos, que são utilizadores autenticados, como contas de serviço ou Grupos Google.

Esta página destina-se a especialistas e operadores de segurança que planeiam e implementam políticas de CAFC para a respetiva organização. Para saber mais acerca das funções comuns e das tarefas de exemplo que referimos no Trusted Cloud by S3NS conteúdo, consulte o artigo Funções e tarefas comuns de utilizadores do GKE.

Antes de ler esta página, certifique-se de que conhece os seguintes conceitos:

• RBAC
• Grupos de APIs Kubernetes
• Recursos da API Kubernetes
• Verbos da API Kubernetes

Para ver uma lista de verificação destas orientações, consulte o Resumo da lista de verificação.

Como funciona o RBAC

O RBAC suporta os seguintes tipos de funções e associações:

• ClusterRole: um conjunto de autorizações que podem ser aplicadas a qualquer espaço de nomes ou a todo o cluster.
• Função: um conjunto de autorizações limitado a um único espaço de nomes.
• ClusterRoleBinding: associa um ClusterRole a um utilizador ou a um grupo para todos os namespaces no cluster.
• RoleBinding: associe um Role ou um ClusterRole a um utilizador ou um grupo num espaço de nomes específico.

Define as autorizações como rules num Role ou num ClusterRole. Cada campo rules numa função consiste num grupo de APIs, nos recursos de API nesse grupo de APIs e nos verbos (ações) permitidos nesses recursos. Opcionalmente, pode restringir os verbos a instâncias com nome de recursos da API usando o campo resourceNames. Para ver um exemplo, consulte o artigo Restrinja o acesso a instâncias de recursos específicas.

Depois de definir uma função, usa um RoleBinding ou um ClusterRoleBinding para associar a função a um assunto. Escolha o tipo de associação com base no facto de querer conceder autorizações num único namespace ou em vários namespaces.

Design de funções RBAC

Use o princípio do menor privilégio

Ao atribuir autorizações numa função RBAC, use o princípio do menor privilégio e conceda as autorizações mínimas necessárias para realizar uma tarefa. A utilização do princípio do menor privilégio reduz o potencial de escalada de privilégios se o seu cluster for comprometido e reduz a probabilidade de o acesso excessivo resultar num incidente de segurança.

Ao criar as suas funções, considere cuidadosamente os riscos comuns de escalada de privilégios, como os verbos escalate ou bind, o acesso create para PersistentVolumes ou o acesso create para Certificate Signing Requests. Para ver uma lista de riscos, consulte o artigo Kubernetes RBAC - privilege escalation risks.

Evite funções e grupos predefinidos

O Kubernetes cria um conjunto de ClusterRoles e ClusterRoleBindings predefinidos que pode usar para a deteção de APIs e para ativar a funcionalidade de componentes geridos. As autorizações concedidas por estas funções predefinidas podem ser extensivas, consoante a função. O Kubernetes também tem um conjunto de utilizadores e grupos de utilizadores predefinidos, identificados pelo prefixo system:. Por predefinição, o Kubernetes e o GKE associam automaticamente estas funções aos grupos predefinidos e a vários assuntos. Para ver uma lista completa das funções predefinidas e das associações que o Kubernetes cria, consulte o artigo Funções e associações de funções predefinidas.

A tabela seguinte descreve algumas funções, utilizadores e grupos predefinidos. Recomendamos que evite interagir com estas funções, utilizadores e grupos, a menos que os tenha avaliado cuidadosamente, porque a interação com estes recursos pode ter consequências não intencionais para a postura de segurança do seu cluster.

Se possível, evite criar associações que envolvam os utilizadores, as funções e os grupos predefinidos. Isto pode ter consequências não intencionais para a postura de segurança do seu cluster. Por exemplo:

• A associação do ClusterRole cluster-admin predefinido ao grupo system:unauthenticated concede a todos os utilizadores não autenticados acesso a todos os recursos no cluster (incluindo segredos). Estas associações altamente privilegiadas são ativamente segmentadas por ataques, como campanhas de software malicioso em massa.
• A associação de uma função personalizada ao grupo system:unauthenticated concede aos utilizadores não autenticados as autorizações concedidas por essa função.

Sempre que possível, siga as seguintes diretrizes:

• Não adicione os seus próprios assuntos ao grupo system:masters.
• Não associe o grupo system:unauthenticated a nenhuma função de RBAC.
• Não associe o grupo system:authenticated a nenhuma função de RBAC.
• Não associe o utilizador system:anonymous a nenhuma função de RBAC.
• Não associe o cluster-admin ClusterRole aos seus próprios assuntos nem a nenhum dos utilizadores e grupos predefinidos. Se a sua aplicação precisar de muitas autorizações, determine as autorizações exatas necessárias e crie uma função específica para esse fim.
• Avalie as autorizações concedidas por outras funções predefinidas antes de associar sujeitos.
• Avalie as funções associadas aos grupos predefinidos antes de modificar os membros desses grupos.

Impeça a utilização de grupos predefinidos

Pode usar a CLI gcloud para desativar associações RBAC não predefinidas num cluster que referenciam os grupos system:unauthenticated e system:authenticated ou o utilizador system:anonymous. Use uma ou ambas as seguintes flags quando criar um novo cluster do GKE ou atualizar um cluster existente. A utilização destas flags não desativa as associações predefinidas do Kubernetes que fazem referência a estes grupos. Estas flags requerem a versão 1.30.1-gke.1283000 ou posterior do GKE.

• --no-enable-insecure-binding-system-authenticated: desative as associações não predefinidas que fazem referência a system:authenticated.
• --no-enable-insecure-binding-system-unauthenticated: desative as associações não predefinidas que fazem referência a system:unauthenticated e system:anonymous.

Detetar e remover a utilização de funções e grupos predefinidos

Para verificar se os seus clusters fazem referência a estes utilizadores e grupos em associações RBAC, ative o nível padrão da análise de postura de segurança do Kubernetes para os seus clusters ou frota, para que o GKE possa mostrar-lhe resultados no painel de controlo de postura de segurança na consola. Trusted Cloud Para ver instruções, consulte Ative a auditoria da configuração da carga de trabalho.

As secções seguintes mostram como encontrar as RoleBindings ou as ClusterRoleBindings específicas que fazem referência a utilizadores e grupos predefinidos, e como eliminar esses recursos.

ClusterRoleBindings

1. Apresente uma lista dos nomes de quaisquer ClusterRoleBindings com o assunto system:anonymous, system:unauthenticated ou system:authenticated:

   kubectl get clusterrolebindings -o json \
     | jq -r '["Name"], ["-----"], (.items[] | select((.subjects | length) > 0) | select(any(.subjects[]; .name == "system:anonymous" or .name == "system:unauthenticated" or .name == "system:authenticated")) | [.metadata.namespace, .metadata.name]) | @tsv'
   

   A saída deve apresentar apenas as seguintes ClusterRoleBindings:

   Name
   ----
   "system:basic-user"
   "system:discovery"
   "system:public-info-viewer"
   

   Se o resultado contiver associações não predefinidas adicionais, faça o seguinte para cada associação adicional. Se a saída não contiver associações não predefinidas, ignore os passos seguintes.

2. Indique as autorizações da função associada à associação:

   kubectl get clusterrolebinding CLUSTER_ROLE_BINDING_NAME -o json \
       | jq ' .roleRef.name +" " + .roleRef.kind' \
       | sed -e 's/"//g' \
       | xargs -l bash -c 'kubectl get $1 $0 -o yaml'
   

   Substitua CLUSTER_ROLE_BINDING_NAME pelo nome da ClusterRoleBinding não predefinida.

   O resultado é semelhante ao seguinte:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
   ...
   rules:
   - apiGroups:
     - ""
     resources:
     - secrets
     verbs:
     - get
     - watch
     - list
   

   Se determinar que as autorizações na saída são seguras para conceder aos utilizadores ou grupos predefinidos, não é necessária nenhuma ação adicional. Se determinar que as autorizações concedidas pela associação não são seguras, avance para o passo seguinte.

3. Elimine uma associação não segura do seu cluster:

   kubectl delete clusterrolebinding CLUSTER_ROLE_BINDING_NAME
   

   Substitua CLUSTER_ROLE_BINDING_NAME pelo nome da ClusterRoleBinding a eliminar.

RoleBindings

1. Liste o espaço de nomes e o nome de quaisquer RoleBindings com o assunto system:anonymous, system:unauthenticated ou system:authenticated:

   kubectl get rolebindings -A -o json \
     | jq -r '["Namespace", "Name"], ["---------", "-----"], (.items[] | select((.subjects | length) > 0) | select(any(.subjects[]; .name == "system:anonymous" or .name == "system:unauthenticated" or .name == "system:authenticated")) | [.metadata.namespace, .metadata.name]) | @tsv'
   

   Se o cluster estiver configurado corretamente, o resultado deve estar em branco. Se o resultado contiver associações não predefinidas, siga os passos seguintes para cada associação adicional. Se o resultado estiver em branco, ignore os passos seguintes.

   Se souber apenas o nome do RoleBinding, pode usar o seguinte comando para encontrar RoleBindings correspondentes em todos os espaços de nomes:

   kubectl get rolebindings -A -o json \
     | jq -r '["Namespace", "Name"], ["---------", "-----"], (.items[] | select((.subjects | length) > 0) | select(.metadata.name == "ROLE_BINDING_NAME") | [.metadata.namespace, .metadata.name]) | @tsv'
   

   Substitua ROLE_BINDING_NAME pelo nome da RoleBinding não predefinida.

2. Indique as autorizações da função associada à associação:

   kubectl get rolebinding ROLE_BINDING_NAME --namespace ROLE_BINDING_NAMESPACE -o json \
       | jq ' .roleRef.name +" " + .roleRef.kind' \
       | sed -e 's/"//g' \
       | xargs -l bash -c 'kubectl get $1 $0 -o yaml --namespace ROLE_BINDING_NAMESPACE'
   

   Substitua o seguinte:

   • ROLE_BINDING_NAME: o nome do RoleBinding não predefinido.
   • ROLE_BINDING_NAMESPACE: o espaço de nomes do RoleBinding não predefinido.

   O resultado é semelhante ao seguinte:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
   ...
   rules:
   - apiGroups:
     - ""
     resources:
     - secrets
     verbs:
     - get
     - watch
     - list
   

   Se determinar que as autorizações na saída são seguras para conceder aos utilizadores ou grupos predefinidos, não é necessária nenhuma ação adicional. Se determinar que as autorizações concedidas pela associação não são seguras, avance para o passo seguinte.

3. Elimine uma associação não segura do seu cluster:

   kubectl delete rolebinding ROLE_BINDING_NAME --namespace ROLE_BINDING_NAMESPACE
   

   Substitua o seguinte:

   • ROLE_BINDING_NAME: o nome do RoleBinding a eliminar.
   • ROLE_BINDING_NAMESPACE: o espaço de nomes do RoleBinding a eliminar.

Restrinja as autorizações ao nível do espaço de nomes

Use associações e funções da seguinte forma, consoante as necessidades da sua carga de trabalho ou utilizador:

• Para conceder acesso a recursos num espaço de nomes , use um Role com um RoleBinding.
• Para conceder acesso a recursos em mais do que um espaço de nomes, use um ClusterRole com um RoleBinding para cada espaço de nomes.
• Para conceder acesso a recursos em todos os espaços de nomes, use um ClusterRole com um ClusterRoleBinding.

Conceda autorizações no menor número possível de espaços de nomes.

Não use carateres universais

O caráter * é um caráter universal que se aplica a tudo. Evite usar carateres universais nas suas regras. Especifique explicitamente grupos de APIs, recursos e verbos nas regras de RBAC. Por exemplo, especificar * no campo verbs concederia permissões get, list, watch, patch, update, deletecollection e delete nos recursos. A tabela seguinte mostra exemplos de como evitar carateres universais nas suas regras:

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

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

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

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

Use regras separadas para conceder acesso com privilégios mínimos a recursos específicos

Ao planear as suas regras, experimente os seguintes passos de nível elevado para um design de regras de privilégios mínimos mais eficiente em cada função:

1. Crie regras RBAC separadas para cada verbo em cada recurso ao qual um sujeito precisa de aceder.
2. Depois de criar as regras, analise-as para verificar se várias regras têm a mesma lista de verbs. Combine essas regras numa única regra.
3. Mantenha todas as regras restantes separadas umas das outras.

Esta abordagem resulta num design de regras 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 estão separadas.

Por exemplo, se a sua carga de trabalho precisar de autorizações para o recurso deployments, mas precisar de list e watch nos recursos daemonsets, deve usar regras separadas quando criar uma função. Quando associa a função RBAC à sua carga de trabalho, não pode usar o watch no deployments.

Como outro exemplo, se a sua carga de trabalho precisar de get e watch no recurso pods e no recurso daemonsets, pode combiná-los numa única regra, porque a carga de trabalho precisa dos mesmos verbos em ambos os recursos.

Na tabela seguinte, ambos os designs de regras funcionam, mas as regras divididas restringem o acesso aos recursos de forma mais detalhada com base nas suas necessidades:

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

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

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

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

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

O RBAC permite-lhe usar o campo resourceNames nas suas regras para restringir o acesso a uma instância específica com nome de um recurso. Por exemplo, se estiver a escrever uma função RBAC que precise de update o seccomp-high ConfigMap e nada mais, pode usar resourceNames para especificar apenas esse ConfigMap. Use resourceNames sempre que possível.

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

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

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

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

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

Não associe recursos Role ou ClusterRole que tenham autorizações bind, escalate, create, update ou patch no grupo de APIs rbac.authorization.k8s.io a contas de serviço em nenhum espaço de nomes. escalate e bind, em particular, podem permitir que um atacante contorne os mecanismos de prevenção de escalonamento incorporados no RBAC.

Contas de serviço do 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. Associe um Role ou um ClusterRole com o mínimo de privilégios a essa conta de serviço.

Não use a conta de serviço predefinida

O Kubernetes cria uma conta de serviço denominada 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 associar um Role ou um ClusterRole à conta de serviço default. O Kubernetes pode atribuir a conta de serviço a um pod que não precisa do acesso concedido nessas funções.default

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

O campo automountServiceAccountToken na especificação do pod indica ao Kubernetes que injete um token de credenciais para uma conta de serviço do Kubernetes no pod. O pod pode usar este token para fazer pedidos autenticados ao servidor da API Kubernetes. O valor predefinido para este campo é true.

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

Preferir tokens efémeros em vez de tokens baseados em segredos

Por predefinição, o processo kubelet no nó obtém um token de conta de serviço de curta duração e rotação automática para cada Pod. O kubelet monta este token no pod como um volume projetado, a menos que defina o campo automountServiceAccountToken como false na especificação do pod. Todas as chamadas à API Kubernetes a partir do pod usam este token para autenticar no servidor da API.

Se estiver a obter manualmente tokens de contas de serviços, evite usar segredos do Kubernetes para armazenar o token. Os tokens de contas de serviço baseados em segredos são credenciais antigas que não expiram e não são rodadas automaticamente. Se precisar de credenciais para contas de serviço, use a API TokenRequest para obter tokens de curta duração que são rodados automaticamente.

Reveja continuamente as autorizações RBAC

Reveja regularmente as suas funções e acesso RBAC para identificar potenciais caminhos de escalamento e regras redundantes. Por exemplo, considere uma situação em que não elimina um RoleBinding que associa um Role com privilégios especiais a um utilizador eliminado. Se um atacante criar uma conta de utilizador nesse espaço de nomes com o mesmo nome que o utilizador eliminado, fica associado a esse Role e herda o mesmo acesso. As revisões periódicas minimizam este risco.

Resumo da lista de verificação

O que se segue?

• Leia as recomendações de reforço de segurança do GKE.
• Leia as boas práticas de RBAC do Kubernetes.
• Explore as nossas outras práticas recomendadas.
• Veja exemplos de manifestos para funções de cluster comuns