Geekly articles weekly

Usuários e autorização do Kubernetes RBAC

Nota perev. : Continuando o tópico de segurança recentemente discutido para o Kubernetes em geral e o RBAC, em particular, estamos publicando uma tradução desse material de um consultor francês da empresa Adaltas Big Data. O autor mostra em detalhes como criar usuários, conceder direitos e continuar a servir.

Configurar e iniciar um cluster Kubernetes é apenas o começo: ele também precisa ser explorado. Para proteger o acesso ao cluster, você precisa definir credenciais do usuário e gerenciar corretamente as configurações de autenticação e autorização.

(Ilustração tirada do blog do CNCF - aprox. Transl.)

Este artigo é sobre como criar usuários usando certificados de cliente X.509 e como gerenciar a autorização usando as APIs RBAC básicas no Kubernetes. Também falaremos sobre alguns projetos de código aberto que simplificam a administração de cluster: rakkess, kubectl-who-can, rbac-lookup e RBAC Manager.

Condições prévias e premissas


Primeiro de tudo, é necessário fazer várias suposições:


Se você não possui um cluster Kubernetes pronto, recomendo que você consulte o artigo de um colega (Arthur BUSSER) no qual ele fala sobre a instalação do Kubernetes no CentOS 7 usando o Vagrant.

Existem 4 nós em nosso cluster: um mestre e três trabalhadores. O assistente também será usado como um nó de borda para interagir com o cluster.

APIs RBAC


O controle de acesso baseado em função (RBAC) é um método para controlar o acesso a computadores e recursos de rede, com base nas funções de usuários individuais em uma empresa. O RBAC pode ser usado com todos os recursos do Kubernetes compatíveis com CRUD (Criar, Ler, Atualizar, Excluir). Exemplos de tais recursos:

  • namespaces
  • Pods
  • Implantações
  • volumes persistentes (PersistentVolumes);
  • ConfigMaps

E aqui estão exemplos de operações possíveis com eles:

  • create ;
  • get
  • delete (excluir) ;
  • list (exibição de list ) ;
  • update .

Para gerenciar o RBAC no Kubernetes, precisamos declarar:

  • Role e ClusterRole . Estes são simplesmente conjuntos de regras que representam um conjunto de permissões. Role pode ser usada apenas para fornecer acesso aos recursos nos espaços para nome. ClusterRole pode fornecer as mesmas permissões que o Role e também fornecer acesso aos recursos disponíveis em todo o cluster e aos chamados pontos de extremidade sem recurso (como /healthz - aprox. Transl.) .
  • Subjects Subject é uma entidade que executará operações em um cluster. Pode ser usuários, serviços ou até grupos.
  • RoleBinding e ClusterRoleBinding . Como o nome indica, isso é simplesmente uma ligação do sujeito a Função ou ClusterRole.

O Kubernetes tem as seguintes funções padrão:

  • view : acesso somente leitura, exclui segredos;
  • edit : o acima + a capacidade de editar a maioria dos recursos, exclui papéis e ligações de papéis;
  • admin : acima + a capacidade de gerenciar funções e mapeamentos de funções no nível do espaço para nome;
  • cluster-admin : todos os privilégios possíveis.

Obviamente, você pode criar suas próprias Roles e ClusterRoles , mas recomendamos que você use as funções padrão o máximo possível, sempre que a situação permitir. Caso contrário, você pode rapidamente se confundir com tudo isso.

Exemplo de uso


Criaremos dois namespaces: my-project-dev e my-project-prod , - assim como dois usuários: jean e sarah - com funções diferentes nesses namespaces:

  • my-project-dev:
    • jean: editar
  • my-project-prod:
    • jean: visualizar
    • sarah: editar

Criar e autenticar usuários usando certificados de cliente X.509


Normalmente, existem dois tipos de usuários: contas de serviço gerenciadas pelo Kubernetes e usuários regulares. Vamos nos concentrar no último. Veja como eles são descritos na documentação oficial:

Supõe-se que usuários regulares sejam gerenciados por um serviço externo independente. O papel pode ser desempenhado por um administrador que distribui chaves privadas, um repositório de usuários como Keystone ou Contas do Google ou mesmo um arquivo com uma lista de nomes de usuário e senhas. Nesse sentido, o Kubernetes não possui objetos que representam usuários comuns. Usuários comuns não podem ser adicionados ao cluster por meio de uma chamada de API.

Existem várias maneiras de gerenciar usuários regulares:

  • Autenticação básica:
    • transferir a configuração para o servidor API com o seguinte conteúdo (ou similar): senha, nome de usuário, uid, grupo;
  • Certificado de Cliente X.509:
    • criação da chave secreta de um usuário e solicitação de assinatura de certificado;
    • certificação em uma autoridade de certificação (Kubernetes CA) para obter um certificado de usuário;
  • Tokens de portador (JSON Web Tokens, JWT):
    • OpenID Connect
    • camada de autenticação sobre o OAuth 2.0;
    • webhooks

Neste artigo, usaremos os certificados X.509 e OpenSSL devido à sua simplicidade. A criação de usuários ocorre em várias etapas - passaremos por todas elas. As operações devem ser executadas na conta do usuário com privilégios de administrador do cluster (cluster-admin). Aqui estão todas as etapas para criar um usuário (usando o jean como exemplo):

  • Crie um usuário no assistente e vá para o diretório inicial para concluir as etapas restantes:

     useradd jean && cd /home/jean
  • Crie uma chave privada:

     openssl genrsa -out jean.key 2048
  • Crie uma solicitação de assinatura de certificado (CSR). CN é o nome de usuário, O é o grupo. Você pode definir permissões por grupo. Isso simplificará o trabalho se, por exemplo, você tiver muitos usuários com as mesmas permissões:

     #   openssl req -new -key jean.key \ -out jean.csr \ -subj "/CN=jean" #     $group openssl req -new -key jean.key \ -out jean.csr \ -subj "/CN=jean/O=$group" #       openssl req -new -key jean.key \ -out jean.csr \ -subj "/CN=jean/O=$group1/O=$group2/O=$group3"
  • Assine CSR em Kubernetes CA. Devemos usar o certificado e a chave da CA, geralmente encontrados em /etc/kubernetes/pki . O certificado será válido por 500 dias:

     openssl x509 -req -in jean.csr \ -CA /etc/kubernetes/pki/ca.crt \ -CAkey /etc/kubernetes/pki/ca.key \ -CAcreateserial \ -out jean.crt -days 500
  • Crie o diretório .certs . Nele, armazenaremos as chaves públicas e privadas do usuário:

     mkdir .certs && mv jean.crt jean.key .certs
  • Crie um usuário dentro do Kubernetes:

     kubectl config set-credentials jean \ --client-certificate=/home/jean/.certs/jean.crt \ --client-key=/home/jean/.certs/jean.key
  • Defina o contexto para o usuário:

     kubectl config set-context jean-context \ --cluster=kubernetes --user=jean
  • Edite o arquivo de configuração do usuário. Ele contém as informações necessárias para autenticação em um cluster. Você pode usar o arquivo de configuração do cluster, que geralmente está em /etc/kubernetes : as variáveis ​​de certificate-authority-data server devem ser as mesmas do arquivo mencionado:

     apiVersion: v1 clusters: - cluster: certificate-authority-data: {  } server: {  } name: kubernetes contexts: - context: cluster: kubernetes user: jean name: jean-context current-context: jean-context kind: Config preferences: {} users: - name: jean user: client-certificate: /home/jean/.certs/jean.cert client-key: /home/jean/.certs/jean.key

    Agora você precisa copiar a configuração acima para o diretório .kube :

     mkdir .kube && vi .kube/config
  • Resta tornar o usuário o proprietário de todos os arquivos e diretórios criados:

     chown -R jean: /home/jean/

O usuário jean criado com sucesso. Faremos o mesmo pelo sarah . Existem algumas etapas e a criação de um grande número de usuários pode levar um longo tempo. Portanto, escrevi scripts Bash que automatizam o processo: eles podem ser encontrados no repositório no GitHub .

Nota perev. : Como escrevemos em nosso artigo recente , esse procedimento pode ser simplificado de uma maneira mais "nativa" para o Kubernetes - por meio de novos recursos no utilitário do console kubeadm . No entanto, lembre-se de que, no momento da publicação desta tradução, eles estavam disponíveis em formato alfa. Um exemplo de comando para criar um usuário é o usuário kubeadm alpha kubeconfig user .

Agora temos usuários e podemos criar dois namespaces:

 kubectl create namespace my-project-dev kubectl create namespace my-project-prod

Como ainda não determinamos a autorização do usuário, eles não devem ter acesso aos recursos do cluster:

 User: Jean kubectl get nodes Error from server (Forbidden): nodes is forbidden: User "jean" cannot list resource "nodes" in API group "" at the cluster scope kubectl get pods -n default Error from server (Forbidden): pods is forbidden: User "jean" cannot list resource "pods" in API group "" in the namespace "default" kubectl get pods -n my-project-prod Error from server (Forbidden): pods is forbidden: User "jean" cannot list resource "pods" in API group "" in the namespace "my-project-prod" kubectl get pods -n my-project-dev Error from server (Forbidden): pods is forbidden: User "jean" cannot list resource "pods" in API group "" in the namespace "my-project-dev" 

 User: Sarah kubectl get nodes Error from server (Forbidden): nodes is forbidden: User "sarah" cannot list resource "nodes" in API group "" at the cluster scope kubectl get pods -n default Error from server (Forbidden): pods is forbidden: User "sarah" cannot list resource "pods" in API group "" in the namespace "default" kubectl get pods -n my-project-prod Error from server (Forbidden): pods is forbidden: User "sarah" cannot list resource "pods" in API group "" in the namespace "my-project-prod" kubectl get pods -n my-project-dev Error from server (Forbidden): pods is forbidden: User "sarah" cannot list resource "pods" in API group "" in the namespace "my-project-dev"

Criação de Função e ClusterRole


Usaremos o ClusterRole , disponível por padrão. No entanto, também mostramos como criar suas próprias Role e Role ClusterRole . Em essência, Role e ClusterRole são apenas um conjunto de ações (chamadas verbs , ou seja, verbos verbais) que são permitidas para determinados recursos e espaços de nomes. Aqui está um exemplo de arquivo YAML:

 apiVersion: rbac.authorization.k8s.io/v1beta1 kind: Role metadata: name: list-deployments namespace: my-project-dev rules: - apiGroups: [ apps ] resources: [ deployments ] verbs: [ get, list ] --------------------------------- apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRole metadata: name: list-deployments rules: - apiGroups: [ apps ] resources: [ deployments ] verbs: [ get, list ]

Para criá-los, execute o comando:

 kubectl create -f /path/to/your/yaml/file

Função de ligação ou função de cluster a usuários


Agora vincule o ClusterRole padrão ( edit e view ) aos nossos usuários da seguinte maneira:

  • jean :
    • edit - no espaço de nomes my-project-dev ;
    • view - no espaço para nome my-project-prod ;
  • sarah :
    • edit - no espaço para nome my-project-prod .

RoleBindings deve ser especificado por namespaces, não por usuários. Em outras palavras, para autorizar o jean , criaremos duas RoleBindings. Um exemplo de um arquivo YAML que define RoleBindings para jean :

 apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: jean namespace: my-project-dev subjects: - kind: User name: jean apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: edit apiGroup: rbac.authorization.k8s.io --------------------------------- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: jean namespace: my-project-prod subjects: - kind: User name: jean apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: view apiGroup: rbac.authorization.k8s.io

jean que o jean view my-project-prod e edite my-project-dev . O mesmo precisa ser feito com autorizações para sarah . Para ativá-los, execute o comando:

 kubectl apply -f /path/to/your/yaml/file

Nesse caso, o kubectl apply foi usado em vez da kubectl create do kubectl create . A diferença entre os dois é que create cria o objeto e não faz mais nada, além de apply - não apenas cria o objeto (se ele não existir), mas também atualiza, se necessário.

Vamos verificar se nossos usuários receberam as permissões necessárias.

  • Usuário: sarah ( edit em my-project-prod )
    • my-project-prod
      • pode listar pods (1);
      • pode criar implantações (2).
    • my-project-dev
      • não pode listar pods (4);
      • não pode criar implantações (5).

 (1) kubectl get pods -n my-project-prod No resources found. (2) kubectl run nginx --image=nginx --replicas=1 -n my-project-prod deployment.apps/nginx created (3) kubectl get pods -n my-project-prod NAME READY STATUS RESTARTS AGE nginx-7db9fccd9b-t14qw 1/1 Running 0 4s (4) kubectl get pods -n my-project-dev Error from server (Forbidden): pods is forbidden: User "sarah" cannot list resource "pods" in API group "" in the namespace "my-project-dev" (5) kubectl run nginx --image=nginx --replicas=1 -n my-project-dev Error from server (Forbidden): deployments.apps is forbidden: User "sarah" cannot create resource "deployments" in API group "apps" in the namespace "my-project-dev"

  • Usuário: jean ( view em my-project-prod e edit em my-project-dev )
    • my-project-prod
      • pode listar pods (1);
      • pode listar deployment'ov (2);
      • não pode excluir implantações (3).
    • my-project-dev:
      • pode listar pods (4);
      • pode criar implantações (5);
      • pode listar deployment'ov (6);
      • pode remover implantações (7).

 (1) kubectl get pods -n my-project-prod NAME READY STATUS RESTARTS AGE nginx-7db9fccd9b-t14qw 1/1 Running 0 101s (2) kubectl get deploy -n my-project-prod NAME READY UP-TO-DATE AVAILABLE AGE nginx 1/1 1 1 110s (3) kubectl delete deploy/nginx -n my-project-prod Error from server (Forbidden): deployments.extensions "nginx" is forbidden: User "jean" cannot delete resource "deployments" in API group "extensions" in the namespace "my-project-prod" (4) kubectl get pods -n my-project-dev No resources found. (5) kubectl run nginx --image=nginx --replicas=1 -n my-project-dev deployment.apps/nginx created (6) kubectl get deploy -n my-project-dev NAME READY UP-TO-DATE AVAILABLE AGE nginx 0/1 1 0 13s (7) kubectl delete deploy/nginx -n my-project-dev deployment.extensions "nginx" deleted (8) kubectl get deploy -n my-project-dev No resources found.

Gerenciamento e autorização de usuário


Portanto, definimos com êxito várias funções e autorizações de usuário. Surge a questão: como agora gerenciar tudo isso? Como sei se as permissões para um usuário específico estão definidas corretamente? Como sei quem tem autoridade para executar uma ação específica? Como obter uma imagem geral das permissões do usuário?

Precisamos de respostas para todas essas perguntas para garantir a segurança do cluster. O kubectl auth can-i permite descobrir se um usuário pode executar uma ação específica:

 # kubectl auth can-i $action $resource --as $subject (1) kubectl auth can-i list pods (2) kubectl auth can-i list pods --as jean

O primeiro comando (1) permite ao usuário descobrir se ele pode executar alguma ação. O segundo (2) - permite que o administrador represente o usuário para descobrir se ele pode executar uma determinada ação. Essa "reencarnação" é permitida apenas para usuários com privilégios de administrador de cluster.

Isso é praticamente tudo o que pode ser feito com o kit de ferramentas interno. É por isso que apresentarei alguns projetos de código aberto que expandem os recursos oferecidos pela equipe kubectl auth can-i. Antes de apresentá-los, vamos estabelecer as dependências: Go e Krew .

Ir instalação


Go é uma linguagem de programação de código aberto que permite criar software simples, confiável e eficiente. Foi desenvolvido pelo Google sob a inspiração de C e Pascal, com base nos conceitos originais de Robert Griesemer , Rob Pike e Ken Thompson .

 wget https://dl.google.com/go/go1.12.5.linux-amd64.tar.gz sudo tar -C /usr/local -xzf go1.12.5.linux-amd64.tar.gz export PATH=$PATH:/usr/local/go/bin

Instalação Krew


Krew é uma ferramenta que simplifica o uso de plugins kubectl . O Krew ajuda a encontrar, instalar e gerenciar plugins. Em termos de funções, assemelha-se a ferramentas como apt, dnf ou brew. O Krew é compatível apenas com o kubectl versão 1.12 e superior.

 set -x; cd "$(mktemp -d)" && curl -fsSLO "https://storage.googleapis.com/krew/v0.2.1/krew.{tar.gz,yaml}" && tar zxvf krew.tar.gz && ./krew-"$(uname | tr '[:upper:]' '[:lower:]')_amd64" install \ --manifest=krew.yaml --archive=krew.tar.gz export PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH"

rakkess


Este projeto permite visualizar todas as permissões que foram concedidas ao usuário. Por exemplo, ajuda a responder à pergunta sobre o que o jean pode fazer. Primeiro de tudo, vamos instalá-lo:

 kubectl krew install access-matrix

A documentação do projeto pode ser encontrada no repositório no GitHub . Aqui está um exemplo de seu trabalho:

 kubectl access-matrix -n my-project-dev --as jean



kubect-who-can


Este projeto nos permite descobrir quais usuários podem executar uma ação específica. Ajuda a responder à pergunta: "Quem pode fazer isso?" Instalação:

 go get -v github.com/aquasecurity/kubectl-who-can

A documentação está no repositório do GitHub . Exemplo de trabalho:

 kubectl-who-can list pods -n default No subjects found with permissions to list pods assigned through RoleBindings CLUSTERROLEBINDING SUBJECT TYPE SA-NAMESPACE cluster-admin system:masters Group rbac-manager rbac-manager ServiceAccount rbac-manager system:controller:attachdetach-controller attachdetach-controller ServiceAccount kube-system system:controller:clusterrole-aggregation-controller clusterrole-aggregation-controller ServiceAccount kube-system system:controller:cronjob-controller cronjob-controller ServiceAccount kube-system system:controller:daemon-set-controller daemon-set-controller ServiceAccount kube-system system:controller:deployment-controller deployment-controller ServiceAccount kube-system system:controller:endpoint-controller endpoint-controller ServiceAccount kube-system system:controller:generic-garbage-collector generic-garbage-collector ServiceAccount kube-system system:controller:horizontal-pod-autoscaler horizontal-pod-autoscaler ServiceAccount kube-system system:controller:job-controller job-controller ServiceAccount kube-system system:controller:namespace-controller namespace-controller ServiceAccount kube-system system:controller:node-controller node-controller ServiceAccount kube-system system:controller:persistent-volume-binder persistent-volume-binder ServiceAccount kube-system system:controller:pod-garbage-collector pod-garbage-collector ServiceAccount kube-system system:controller:pvc-protection-controller pvc-protection-controller ServiceAccount kube-system system:controller:replicaset-controller replicaset-controller ServiceAccount kube-system system:controller:replication-controller replication-controller ServiceAccount kube-system system:controller:resourcequota-controller resourcequota-controller ServiceAccount kube-system system:controller:statefulset-controller statefulset-controller ServiceAccount kube-system system:coredns coredns ServiceAccount kube-system system:kube-controller-manager system:kube-controller-manager User system:kube-scheduler system:kube-scheduler User

rbac-lookup


Este projeto fornece uma visão geral das regras do RBAC. Ajuda a responder às perguntas: “A que papel jean e sarah pertencem?”, “A que papel pertencem todos os usuários?”, “A que papel pertence todo o grupo?”. Para instalar, execute o comando:

 kubectl krew install rbac-lookup

A documentação está no repositório do GitHub . Aqui está um exemplo de trabalho:

 kubectl-rbac_lookup jean SUBJECT SCOPE ROLE jean my-project-dev ClusterRole/edit jean my-project-prod ClusterRole/view kubectl-rbac_lookup sarah SUBJECT SCOPE ROLE sarah my-project-prod ClusterRole/edit kubectl-rbac_lookup --kind user SUBJECT SCOPE ROLE jean my-project-dev ClusterRole/edit jean my-project-prod ClusterRole/view sarah my-project-prod ClusterRole/edit system:anonymous kube-public Role/kubeadm:bootstrap-signer-clusterinfo system:kube-controller-manager kube-system Role/extension-apiserver-authentication-reader system:kube-controller-manager kube-system Role/system::leader-locking-kube-controller-manager system:kube-controller-manager cluster-wide ClusterRole/system:kube-controller-manager system:kube-proxy cluster-wide ClusterRole/system:node-proxier system:kube-scheduler kube-system Role/extension-apiserver-authentication-reader system:kube-scheduler kube-system Role/system::leader-locking-kube-scheduler system:kube-scheduler cluster-wide ClusterRole/system:kube-scheduler system:kube-scheduler cluster-wide ClusterRole/system:volume-scheduler kubectl-rbac_lookup --kind group SUBJECT SCOPE ROLE system:authenticated cluster-wide ClusterRole/system:basic-user system:authenticated cluster-wide ClusterRole/system:discovery system:authenticated cluster-wide ClusterRole/system:public-info-viewer system:bootstrappers:kubeadm:default-node-token cluster-wide ClusterRole/system:node-bootstrapper system:bootstrappers:kubeadm:default-node-token cluster-wide ClusterRole/system:certificates.k8s.io:certificatesigningrequests:nodeclient system:bootstrappers:kubeadm:default-node-token kube-system Role/kube-proxy system:bootstrappers:kubeadm:default-node-token kube-system Role/kubeadm:kubelet-config-1.14 system:bootstrappers:kubeadm:default-node-token kube-system Role/kubeadm:nodes-kubeadm-config system:masters cluster-wide ClusterRole/cluster-admin system:nodes kube-system Role/kubeadm:kubelet-config-1.14 system:nodes kube-system Role/kubeadm:nodes-kubeadm-config system:nodes cluster-wide ClusterRole/system:certificates.k8s.io:certificatesigningrequests:selfnodeclient system:unauthenticated cluster-wide ClusterRole/system:public-info-viewer

Gerente RBAC


Como o nome deste projeto obviamente implica, ele é o gerente do RBAC. Simplifica as muitas manipulações necessárias. Talvez o mais importante seja a criação de RoleBindings. Vimos anteriormente que, ao criar funções diferentes para um usuário, é necessário criar RoleBindings diferentes. O RBAC Manager ajuda, permitindo que você faça apenas um RoleBinding com toda a autorização de uma só vez. Para instalar, você deve baixar o arquivo YAML do repositório no GitHub:

 kubectl apply -f /path/to/rbac/manager/yaml/file

A documentação oficial está no repositório do GitHub . Exemplo de trabalho:

 apiVersion: rbacmanager.reactiveops.io/v1beta1 kind: RBACDefinition metadata: name: jose rbacBindings: - name: jose subjects: - kind: User name: jose roleBindings: - namespace: my-project-prod clusterRole: edit - namespace: my-project-dev clusterRole: edit

Conclusão


Criamos usuários no cluster Kubernetes usando o certificado de cliente X.509 com OpenSSL e os capacitamos. Para facilitar a criação do usuário, você pode usar o script disponível no meu repositório no GitHub (ou os comandos experimentais do kubeadm - aprox. Transl.) . Quanto à administração de cluster, você pode usar os projetos de código aberto apresentados no artigo:

  • kubectl auth can-i : descubra se o usuário pode executar alguma ação;
  • rakkess : descubra todas as ações que o usuário pode executar;
  • kubectl-who-can : determina quais usuários podem executar alguma ação;
  • rbac-lookup : obtenha uma visão geral do RBAC;
  • Gerenciador RBAC : simplifique a configuração combinando ligações de direitos, automatizando alterações no RBAC, usando rótulos como seletores para atribuir direitos.

Criar usuários pode se transformar em uma tarefa muito demorada, especialmente se você precisar definir um grande número de usuários por vez (ou criá-los com frequência). Para aliviar a situação, é possível conectar o LDAP corporativo ao cluster Kubernetes. Alguns projetos de código aberto ( Kismatic [ Object parece abandonado] e ObjectifLibre ) oferecem webhooks do Kubernetes que permitem autenticação direta através do LDAP. Outra solução possível é configurar um servidor OpenID com o LDAP corporativo como back-end.

PS do tradutor


Leia também em nosso blog:

Source: https://habr.com/ru/post/pt470503/

More articles:


All Articles