Proteger o cluster Kubernetes é uma coisa, mas manter a segurança ainda é um desafio. No entanto, novas ferramentas foram adicionadas ao Kubernetes: agora é muito mais fácil fazer as duas coisas.
O Kubernetes (desde a versão 1.6) introduziu o conceito de controle de acesso baseado em função (RBAC), que permite aos administradores definir políticas de restrição para usuários de cluster. Ou seja, você cria um usuário com acesso limitado: limite o acesso do usuário a recursos como segredos ou a determinados namespaces.
Neste post, não entenderemos como implementar o RBAC. Existem fontes decentes suficientes para discutir este tópico de e para:
É melhor focar em como garantir que os requisitos de sua empresa sejam atendidos e verificar se os objetos RBAC em execução precisam ser verificados para verificar se eles desempenham suas funções.
Nosso roteiro
Algumas organizações aceitam vários grupos para trabalhar com o novo cluster Kubernetes. Há um requisito: você não pode interferir na implantação de um grupo vizinho, para que não haja problemas imprevisíveis entre grupos ou paradas.
E, assim, o proprietário do cluster implantou o RBAC no cluster, limitando assim o acesso a um espaço para nome específico. A primeira verificação mostrou: os grupos não podem visualizar os pods uns dos outros no espaço para nome.
Uma semana se passou. O proprietário do cluster notou que um usuário de um espaço para nome isolado está lendo segredos de outro espaço para nome. Como assim? Ele usou RBAC!
Eu o apliquei, mas, como no trabalho com código, o sistema deve ser testado quanto à conformidade com o resultado desejado. É bom que a kubectl kubectl CLI Kubernetes forneça um conjunto de ferramentas para verificar a configuração do RBAC. kubectl auth can-i
Posso? ("Posso?")
can-i usando a API, apenas verifica se uma determinada ação pode ser executada. Ele usa os seguintes parâmetros: kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL] kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL] kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL] . Agora, o usuário atual pode verificar se uma ação específica está disponível para ele. Vamos lá:
kubectl auth can-i create pods
Isso deve retornar uma resposta "sim" ou "não" com o código de saída apropriado.
No entanto, ao tentar verificar os direitos de outro usuário, encontramos um problema: o usuário sob o qual estamos autorizados no cluster é especificado no arquivo de configuração ./kube/config e é inconveniente ter configurações separadas para testar usuários individuais. Felizmente, o Kubernetes volta a resgatar: é capaz de simular usuários usando os rótulos --as= e --as-group= .
Atualize o comando, use a simulação de outro usuário:
kubectl auth can-i create pods --as=me
Devemos ver que, com o código de saída 1 , a resposta "não" é retornada.
E isso é ótimo, porque agora temos um conjunto de comandos que permitem verificar se um usuário ou grupo de usuários tem acesso a algum recurso do Kubernetes - desde a visualização de pods até a exclusão de segredos.
Automação
No entanto, é muito cedo para parar: agora podemos implementar uma sequência de testes que descreverá a lista de requisitos e executará como parte do pipeline do CD. Para a causa!
Há muito por onde escolher, há linguagens suficientes para implementar: começando com Ava e Mocha em JavaScript e terminando com Rspec. Nesse caso, implementei a estrutura de teste puramente Bash Bats .
Abaixo está um exemplo de execução de um teste. Ele verifica a operação das regras RBAC que permitem que um usuário de um grupo altere o número de lares em execução no espaço para nome. É executado se o atributo "executável" tiver sido definido. Ou - usando o bats filename .
#!/usr/bin/env bats @test "Team namespaces can scale deployments within their own namespace" { run kubectl auth can-i update deployments.apps --subresource="scale" --as-group="$group" --as="$user" -n $ns [ "$status" -eq 0 ] [ "$output" == "yes" ] done }
Os --as-group --as e --as-group requerem o uso das seguintes regras RBAC:
rules: - apiGroups: - authorization.k8s.io resources: - selfsubjectaccessreviews - selfsubjectrulesreviews verbs: - create
Aqui está um método simples para você implementar verificações em suas regras RBAC no Kubernetes. Ao fazer parte do pipeline de Kubernetes, fortaleceremos significativamente a política de RBAC. O método foi testado na prática: capturar alterações que violam as políticas de acesso é muito mais rápido!
Obrigado por ler este post!