[ad_1]
O controle de acesso baseado em função (RBAC) é um mecanismo para definir as ações que as contas de usuário podem executar em seu cluster Kubernetes. Habilitar o RBAC reduz o risco associado ao roubo de credenciais e controle de contas. Dar a cada usuário o conjunto mínimo de permissões necessárias evita que as contas adquiram privilégios excessivos.
As distribuições mais populares do Kubernetes começam com uma única conta de usuário que recebe acesso de superusuário ao cluster. Autenticar como esta conta permite que você execute qualquer ação, mas pode representar um risco de segurança substancial.
Neste artigo, mostraremos como habilitar e configurar a API RBAC do Kubernetes para que você possa ajustar os recursos do usuário. é comum que alguns usuários criem e listem apenas Pods, enquanto os administradores também podem excluir itens. Você pode configurar e aplicar essas políticas por meio do sistema RBAC.
Habilitando o RBAC no Kubernetes
O RBAC é um recurso opcional do Kubernetes, mas a maioria das principais distribuições vem com ele ativado por padrão, incluindo os de provedores de nuvem gerenciados. Você pode verificar se o RBAC está disponível em seu cluster executando o seguinte comando com Kubectl:
$ kubectl api-versions | grep rbac.authorization.k8s rbac.authorization.k8s.io/v1
O comando deve emitir rbac.authorization.k8s.io/v1 como sua saída se o RBAC estiver habilitado. O RBAC é desativado se o comando não produzir nenhum resultado. Você pode ativá-lo iniciando o servidor da API Kubernetes com o --authorization-mode=RBAC bandeira:
$ kube-apiserver --authorization-mode=RBAC
Consulte a documentação da sua distribuição do Kubernetes se não tiver certeza de como personalizar os argumentos de inicialização do servidor de API.
Objetos RBAC do Kubernetes
A implementação do Kubernetes RBAC gira em torno de quatro tipos de objetos diferentes. Você pode gerenciar esses objetos com o Kubectl, semelhante a outros recursos do Kubernetes, como Pods, Deployments e ConfigMaps.
- Função – Uma função é um conjunto de regras de controle de acesso que definem as ações que os usuários podem executar.
- link de função – Um “link” é um link entre uma função e um ou mais assuntos, que podem ser usuários ou contas de serviço. O link permite que os sujeitos executem qualquer uma das ações incluídas na função de destino.
Roles e RoleBindings são objetos com namespace. Eles devem existir em um namespace específico e controlar o acesso a outros objetos dentro dele. O RBAC é aplicado a recursos em nível de cluster, como os próprios nós e namespaces, usando ClusterRoles S ClusterRoleBindings. Eles funcionam de maneira semelhante a Roles e RoleBindings, mas visam objetos sem namespace.
Criar uma conta de serviço
Uma conta de serviço do Kubernetes é um tipo de usuário gerenciado pela API do Kubernetes. Cada conta de serviço tem um token exclusivo que é usado como credenciais. Você não pode adicionar usuários regulares por meio da API do Kubernetes, então usaremos uma conta de serviço para este tutorial.
Use o Kubectl para criar uma nova conta de serviço:
$ kubectl create serviceaccount demo
Isso produz uma nova conta chamada demo. Em seguida, você precisa recuperar o token que usará para autenticar como esta conta. Primeiro encontre o nome do segredo que armazena o token:
$ kubectl describe serviceaccount demo Name: demo Namespace: default Labels: <none> Annotations: <none> Image pull secrets: <none> Mountable secrets: demo-token-w543b Tokens: demo-token-w543b Events: <none>
O token para esta conta de serviço é armazenado no segredo chamado demo-token-w543b. Você pode recuperar o token obtendo o valor do segredo com este comando:
$ TOKEN=$(kubectl describe secret demo-token-w543b | grep token: | awk '{print $2}')
O token agora é armazenado no TOKEN variável em seu shell. Você pode usar essa variável para adicionar um novo contexto Kubectl que permitirá a autenticação como sua conta de serviço:
$ kubectl config set-credentials demo --token=$TOKEN User "demo" set. $ kubectl config set-context demo --cluster=default --user=demo Context "demo" created.
Você deve alterar o valor de --cluster sinalizador para corresponder ao nome de sua conexão de cluster Kubectl ativa. isso geralmente é default ou o nome do contexto atualmente selecionado. Você pode verificar o contexto selecionado executando kubectl config current-context.
Mude para seu novo contexto para autenticar como seu demo conta de serviço Anote primeiro o nome do contexto selecionado no momento, para que você possa retornar à sua conta de superusuário mais tarde.
$ kubectl config current-context default $ kubectl config use-context demo Switched to context "demo".
Os comandos do Kubectl agora serão autenticados como o demo conta de serviço Tente recuperar a lista de pods em seu cluster:
$ kubectl get pods Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:default:demo" cannot list resource "pods" in API group "" in the namespace "default"
A operação foi proibida porque o demo a conta de serviço não tem uma função que permita acessar os pods.
Adicionar uma função
As funções são criadas da mesma forma que qualquer outro objeto do Kubernetes. Escreva um arquivo YAML que defina a função e as permissões que ela fornece. Cada função contém uma ou mais regras que permitem que ações específicas sejam executadas em um conjunto de recursos. Aqui está uma função simples que permite que um usuário recupere detalhes de pods existentes:
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: demo-role rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list"]
a get S list Verbos aplicados a pods resource significa que você poderá executar comandos como get pod S describe pod. A tentativa de criar um novo Pod ou excluir um existente será proibida porque o create S delete os verbos são omitidos da função.
Volte ao contexto original do Kubectl para adicionar a função ao cluster usando sua conta administrativa:
$ kubectl config use-context default Switched to context "default".
Agora adicione a função:
$ kubectl apply -f role.yaml role.rbac.authorization.k8s.io/demo-role created
Como vincular funções a usuários e contas de serviço
Agora você pode associar sua função à sua demo conta de serviço criando um novo RoleBinding. Crie o seguinte arquivo YAML para definir seu link:
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: namespace: default name: demo-role-binding subjects: - kind: ServiceAccount name: demo apiGroup: "" roleRef: kind: Role name: demo-role apiGroup: ""
RoleBindings deve incluir um ou mais assuntos que identificam os usuários e contas de serviço visados pela associação. a roleRef O campo refere-se à função que você deseja atribuir a cada um desses usuários.
Role e RoleBinding devem existir no mesmo namespace. Use um ClusterRole e um ClusterRoleBinding para recursos sem namespaces.
próxima corrida kubectl apply para adicionar RoleBinding ao seu cluster. Entrará em vigor imediatamente, concedendo a demo conta de serviço as capacidades declaradas no demo-role Função:
$ kubectl apply -f role-binding.yaml rolebinding.rbac.authorization.k8s.io/demo-role-binding created
Teste sua regra RBAC
Teste sua implementação simples do RBAC voltando ao novo contexto Kubectl que você criou para o demo conta:
$ kubectl config use-context demo Switched to context "demo".
Agora repita o get pods comando de antes:
$ kubectl get pods No resources found in default namespace.
Desta vez o comando foi bem sucedido. a demo a conta de serviço agora pode recuperar listas de pods porque está vinculada ao demo-role Função. Você ainda verá um erro Forbidden se tentar criar um novo pod porque essa operação não está incluída em nenhuma função vinculada à conta:
$ kubectl run nginx --image=nginx Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:default:demo" cannot create resource "pods" in API group "" in the namespace "default"
Você pode resolver isso atribuindo ao usuário outra função que inclua o create verbo para ele pods recurso. Como alternativa, você pode editar o arquivo YAML da função existente e aplicar a versão modificada ao cluster:
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: demo-role rules: - apiGroups: [""] resources: ["pods"] verbs: ["create", "get", "list"]
Você também pode adicionar regras adicionais à sua função para criar diferentes combinações de grupos de recursos e ações permitidas.
Resumo
O RBAC permite definir os recursos de software disponíveis para contas de usuários individuais. O sistema Kubernetes RBAC fornece controles detalhados para limitar os tipos de recursos que as contas podem acessar e as ações que podem realizar.
A adoção do RBAC fortalece a segurança em seu cluster e cria um ambiente operacional menos arriscado. No entanto, você ainda deve estar ciente das práticas recomendadas para evitar a introdução de novos problemas. Você deve auditar regularmente seu cluster para identificar contas com privilégios excessivos e limpar funções redundantes. Isso ajudará a evitar confusão e permitirá que você tenha uma visão clara de quais ações cada conta pode realizar.
Implementações eficazes de RBAC devem ser baseadas no menor número de funções possível, com cada função tendo o conjunto mínimo de ações necessárias para sua área específica de funcionalidade. A atribuição de muitos privilégios a cada conta nega os benefícios do RBAC, portanto, vale a pena gastar tempo planejando os requisitos para cada usuário antes de começar a criar funções e associações.
[ad_2]
