Controle de acesso baseado em papéis

Nesta página, você encontra uma visão geral do controle de acesso baseado em papéis no Kubernetes Engine.

Visão geral

Com o controle de acesso baseado em papéis (RBAC, na sigla em inglês) do Kubernetes Engine, controle detalhadamente como os usuários acessam os recursos da Kubernetes API executados no cluster de contêiner. Use esse controle para configurar dinamicamente as permissões dos usuários do cluster e definir os tipos de recursos com os quais eles podem interagir.

É possível criar permissões de controle de acesso que se aplicam a todo o cluster ou a namespaces específicos dentro do cluster. As permissões em todo o cluster são úteis para limitar o acesso de alguns usuários a recursos específicos da API, como políticas de segurança ou chaves secretas. As permissões específicas de namespace são usadas quando, por exemplo, você tem vários grupos de usuários que operam em namespaces próprios. O controle de acesso baseado em papéis ajuda você a garantir que os usuários tenham acesso somente aos recursos do cluster dos respectivos namespaces.

Observação: por padrão, o controle de acesso baseado em papéis é ativado em todos os clusters de contêiner que executam a versão 1.6 ou posteriores do Kubernetes.

Interação com o gerenciamento de identidade e acesso

No Kubernetes Engine, o gerenciamento de identidade e acesso (IAM, na sigla em inglês) também é usado para controlar o acesso ao cluster de contêiner. Entretanto, o IAM funciona com base nos projetos, ou seja, os usuários precisam de permissões de IAM para acessar os clusters de um projeto do Cloud Platform.

Com as permissões do controle de acesso baseado em papéis, você tem um controle mais detalhado sobre o acesso aos recursos de cada cluster. Com isso, o gerenciamento de identidade e acesso e o controle baseado em papéis funcionam em conjunto. Para trabalhar com os recursos do cluster, o usuário precisa ter as permissões necessárias para cada nível.

Pré-requisitos para usar o controle de acesso baseado em papéis

Para clusters do Kubernetes Engine com versões 1.6 ou 1.7 do Kubernetes, é preciso criar ou fazer upgrade do cluster com a opção --no-enable-legacy-authorization para garantir que as permissões de controle de acesso baseadas em papéis entrem em vigor.

Depois que o cluster tiver o autorizador de legado desativado, é preciso conceder ao usuário a capacidade de criar papéis de autorização executando o seguinte comando do Kubernetes:

kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin [--user=<user-name>]

Observação: nas versões 1.6 e 1.7 do Kubernetes, os clusters do Kubernetes Engine também contêm um sistema de autorização legado.No Kubernetes, os autorizadores interagem mediante a concessão de uma autorização se qualquer autorizador concede a permissão. O autorizador do legado no Kubernetes Engine concede permissões amplas e estatisticamente definidas. Para garantir que o RBAC limite as permissões corretamente, é necessário desativar o autorizador do legado.

Os clusters do Kubernetes Engine que executam a versão 1.8 e posteriores do Kubernetes desativam o sistema de autorização legado por padrão e, portanto, as permissões de controle de acesso baseadas em papéis entram em vigor sem que nenhuma ação especial seja necessária.

Como configurar o controle de acesso baseado em papéis

Para definir as permissões do controle de acesso baseado em papéis, basta criar objetos do grupo da API rbac.authorization.k8s.io no cluster. Faça isso com a interface de linha de comando kubectl ou por programação.

Dois tipos de objetos precisam ser criados:

1. Um objeto Role ou ClusterRole que define os tipos de recurso e as operações permitidos para um conjunto de usuários.
2. Um RoleBinding ou ClusterRoleBinding que associa o Role ou ClusterRole a um ou mais usuários específicos.

As permissões do controle de acesso baseado em papéis só precisam ser adicionadas, não há regras de "negação". Ao estruturar essas permissões, pense em termos de "conceder" o acesso aos recursos do cluster para os usuários.

Como definir permissões em um Role

As permissões são definidas no objeto da API Role ou ClusterRole do Kubernetes. Com um Role, conceda acesso aos recursos de um único namespace. Com um ClusterRole, o acesso é concedido aos recursos de todo o cluster.

Dentro do objeto Role ou ClusterRole, defina as permissões como um conjunto de rules. As rules determinam namespace, tipo de recurso e operações permitidas desse papel. Por exemplo, crie um Role com acesso de leitura, ou seja, operações get, watch e list, em todos os recursos do pod de um determinado namespace.

Devido à forma como o Kubernetes Engine verifica as permissões quando você cria um Role ou ClusterRole, primeiro crie uma RoleBinding que conceda a você todas as permissões incluídas no papel que quer criar.

Por exemplo, uma alternativa é criar um RoleBinding que atribua o papel de cluster-admin à sua identidade do Google antes de definir permissões adicionais do Role ou ClusterRole.

Este é um problema conhecido no RBAC nas versões 1.6 e posteriores do Kubernetes e do Kubernetes Engine.

Role vs. ClusterRole

Como as permissões do ClusterRole são aplicadas em todo o cluster, elas podem ser usadas para controlar o acesso a tipos de recursos diferentes dos tipos possíveis com um Role. São eles:

• recursos do escopo do cluster, por exemplo, nodes
• pontos de extremidade que não são recursos, por exemplo, /healthz
• recursos com namespace, em todos os namespaces, por exemplo, todos os pods do cluster, independente do namespace

Atribuir permissões aos usuários com RoleBinding

Depois de criar o Role ou ClusterRole, crie um objeto RoleBinding ou ClusterRoleBinding para conceder as permissões do Role ou ClusterRole a um conjunto de usuários. Eles podem ser usuários individuais ou contas de serviço do Kubernetes.

O RoleBinding ou ClusterRoleBinding contém uma lista de usuários e uma referência ao Role ou ClusterRole atribuído a eles.

Observação: não é possível atribuir permissão aos Grupos do Google com o RBAC. Você pode atribuir permissão para grupos usando o IAM.

Cuidado: em clusters com Kubernetes 1.6 ou 1.7, as contas de serviço do Kubernetes têm permissões completas na Kubernetes API por padrão.Para garantir que suas permissões de controle de acesso baseadas em papéis tenham efeito para uma conta de serviço Kubernetes, é preciso criar ou atualizar seu cluster com a opção --no-enable-legacy-authorization. Esse requisito é removido para clusters com Kubernetes versão 1.8 ou posterior.

Uso e exemplos da API

Para informações completas sobre como usar a Kubernetes API para criar os objetos Role, ClusterRole, RoleBinding e ClusterRoleBinding necessários para o RBAC, consulte Como usar permissões do controle de acesso baseado em papéis na documentação do Kubernetes.

Próximas etapas

• Leia sobre a configuração do gerenciamento de identidade e acesso.