|
Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official. |
Comunicando-se com clusters de usuários descendentes
Esta seção descreve como o Rancher provisiona e gerencia os clusters de usuários descendentes que executam seus aplicativos e serviços.
O diagrama abaixo mostra como os controladores de cluster, agentes de cluster e o agente do sistema Rancher permitem que o Rancher controle os clusters descendentes.
As seguintes descrições correspondem aos números no diagrama acima:
1. O Proxy de Autenticação
Neste diagrama, um usuário chamado Bob deseja ver todos os pods em execução em um cluster de usuários descendentes chamado User Cluster 1. A partir do Rancher, ele pode executar um comando kubectl para ver os pods. Bob é autenticado através do proxy de autenticação do Rancher.
O proxy de autenticação encaminha todas as chamadas da API do Kubernetes para clusters descendentes. Ele se integra a serviços de autenticação como autenticação local, Active Directory e GitHub. Em cada chamada da API do Kubernetes, o proxy de autenticação autentica o chamador e define os cabeçalhos de impersonação do Kubernetes adequados antes de encaminhar a chamada para os mestres do Kubernetes.
O Rancher se comunica com clusters do Kubernetes usando uma conta de serviço. Cada conta de usuário no Rancher correlaciona-se com uma conta de serviço equivalente no cluster descendente. O Rancher usa a conta de serviço para impersonar o usuário, o que fornece todas as permissões que o usuário deve ter.
Por padrão, o Rancher gera um arquivo kubeconfig que contém credenciais para fazer proxy através do servidor Rancher e se conectar ao servidor da API Kubernetes em um cluster de usuários descendente. O arquivo kubeconfig (kube_config_rancher-cluster.yml) contém acesso total ao cluster.
2. Controladores de Cluster e Agentes de Cluster
Cada cluster de usuários descendente possui um agente de cluster, que abre um túnel para o controlador de cluster correspondente dentro do servidor Rancher.
Há um controlador de cluster e um agente de cluster para cada cluster descendente. Cada controlador de cluster:
-
Monitora as mudanças de recursos no cluster descendente
-
Leva o estado atual do cluster descendente ao estado desejado
-
Configura políticas de controle de acesso para clusters e projetos
-
Provisiona clusters chamando os drivers de máquina Docker e motores Kubernetes necessários, como GKE
Por padrão, para permitir que o Rancher se comunique com um cluster descendente, o controlador de cluster se conecta ao agente de cluster. Se o agente de cluster não estiver disponível, o controlador de cluster pode se conectar a um agente do sistema Rancher em vez disso.
O agente de cluster, também chamado de cattle-cluster-agent, é um componente que roda em um cluster de usuários descendente. Ele executa as seguintes tarefas:
-
Conecta-se à API Kubernetes de clusters Kubernetes iniciados pelo Rancher
-
Gerencia cargas de trabalho, criação e implantação de pods dentro de cada cluster
-
Aplica os papéis e vinculações definidos nas políticas globais de cada cluster
-
Comunica entre o cluster e o servidor Rancher (através de um túnel para o controlador do cluster) sobre eventos, estatísticas, informações dos nós e saúde
3. Agente do sistema Rancher
Se o agente do cluster (também chamado de cattle-cluster-agent) não estiver disponível, o agente do sistema Rancher cria um túnel para o controlador do cluster para se comunicar com o Rancher.
O rancher-system-agent é executado em cada nó nos clusters Kubernetes RKE2 e K3s. É usado para interagir com os nós ao realizar operações no cluster. Exemplos de operações no cluster incluem atualizar a versão do Kubernetes e criar ou restaurar instantâneos do etcd.
4. Ponto de Extremidade de Cluster Autorizado
Um ponto de extremidade de cluster autorizado (ACE) permite que os usuários se conectem ao servidor da API do Kubernetes de um cluster descendente sem precisar direcionar suas solicitações através do proxy de autenticação do Rancher.
O ACE está disponível em clusters RKE2 e K3s que são provisionados ou registrados com o Rancher. Não está disponível em clusters em um provedor de Kubernetes hospedado, como o EKS da Amazon.
Existem duas razões principais pelas quais um usuário pode precisar do ponto de extremidade de cluster autorizado:
-
Para acessar um cluster de usuário descendente enquanto o Rancher está fora do ar
-
Para reduzir a latência em situações em que o servidor Rancher e o cluster descendente estão separados por uma longa distância
O microserviço kube-api-auth é implantado para fornecer a funcionalidade de autenticação do usuário para o ponto de extremidade de cluster autorizado. Quando você acessa o cluster de usuário usando kubectl, o servidor da API do Kubernetes do cluster autentica você usando o serviço kube-api-auth como um webhook.
Assim como o ponto de extremidade de cluster autorizado, o serviço de autenticação kube-api-auth também está disponível apenas para clusters Kubernetes lançados pelo Rancher.
Exemplo de cenário: Vamos supor que o servidor Rancher esteja localizado nos Estados Unidos, e o Cluster de Usuário 1 esteja localizado na Austrália. Uma usuária, Alice, também vive na Austrália. Alice pode manipular recursos no Cluster de Usuário 1 usando a interface do Rancher, mas suas solicitações terão que ser enviadas da Austrália para o servidor Rancher nos Estados Unidos, e depois serem redirecionadas de volta por meio do proxy para a Austrália, onde está o cluster de usuário downstream. A distância geográfica pode causar latência significativa, que Alice pode reduzir usando o ponto de extremidade de cluster autorizado.
Com este endpoint habilitado para o cluster descendente, o Rancher gera um contexto Kubernetes adicional no arquivo kubeconfig para se conectar diretamente ao cluster. Este arquivo contém as credenciais para kubectl e helm.
|
Para usar o contexto ACE no seu kubeconfig, execute |
Para mais informações, consulte a seção sobre como acessar seu cluster com kubectl e o arquivo kubeconfig.
Recomendamos exportar o arquivo kubeconfig para que, se o Rancher falhar, você ainda possa usar as credenciais no arquivo para acessar seu cluster.
Representação
Os usuários tecnicamente existem apenas no cluster upstream. O Rancher cria RoleBindings e ClusterRoleBindings que se referem a usuários do Rancher, mesmo que não haja nenhum recurso de Usuário real no cluster descendente.
Quando os usuários interagem com um cluster descendente por meio do proxy de autenticação, precisa haver alguma entidade no cluster descendente para servir como o ator para essas solicitações. O Rancher cria contas de serviço para ser essa entidade. Cada conta de serviço recebe apenas uma permissão, que é impersonar o usuário ao qual pertence. Se houvesse apenas uma conta de serviço que pudesse impersonar qualquer usuário, então seria possível para um usuário malicioso corromper essa conta e escalar seus privilégios ao impersonar outro usuário. Esse problema foi a base para um CVE.
Solução de Problemas de Impersonação
No downstream cluster, cinco recursos lidam com impersonação:
-
namespace:
cattle-impersonation-system -
conta de serviço:
cattle-impersonation-system/cattle-impersonation-<user ID> -
segredo do token da conta:
cattle-impersonation-system/cattle-impersonation-<user ID>-token-<hash> -
papel de cluster:
cattle-impersonation-<user ID> -
vinculação de papel de cluster:
cattle-impersonation-<user ID>
Neste exemplo de um papel de cluster típico de impersonação, o sistema está configurado para usar github como o provedor de autenticação:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
creationTimestamp: "2021-10-06T18:20:13Z"
labels:
authz.cluster.cattle.io/impersonator: "true"
cattle.io/creator: norman
name: cattle-impersonation-user-abcde
resourceVersion: "3528"
uid: a7478731-72a0-4343-b09f-c3bf12552d77
rules:
# allowed to impersonate user user-abcde
- apiGroups:
- ""
resourceNames:
- user-abcde
resources:
- users
verbs:
- impersonate
# allowed to impersonate listed groups
- apiGroups:
- ""
resourceNames:
- github_team://123 # group from GitHub auth provider
- system:authenticated # automatic group from Kubernetes
- system:cattle:authenticated # automatic group from Rancher
resources:
- groups
verbs:
- impersonate
# allowed to impersonate principal ID github_user://098
- apiGroups:
- authentication.k8s.io
resourceNames:
- github_user://098 # principal ID from GitHub auth provider
resources:
- userextras/principalid
verbs:
- impersonate
# allowed to impersonate username example
- apiGroups:
- authentication.k8s.io
resourceNames:
- example # username from GitHub auth provider
resources:
- userextras/username
verbs:
- impersonateAo solucionar problemas de impersonação, verifique se esses recursos existem para o usuário e se as regras no papel do cluster são semelhantes às acima. Por exemplo:
kubectl --namespace cattle-impersonation-system get serviceaccount cattle-impersonation-<user ID>
kubectl --namespace cattle-impersonation-system get secret cattle-impersonation-<user ID>-token-<hash>
kubectl get clusterrole cattle-impersonation-<user ID> --output yaml
kubectl get clusterrolebinding cattle-impersonation-<user ID>Se você ver um erro relacionado a "impersonação" na interface do usuário, preste atenção especial ao end da mensagem de erro, que deve indicar a verdadeira razão pela qual a solicitação falhou.
Arquivos Importantes
Os arquivos mencionados abaixo são necessários para manter, solucionar problemas e fazer upgrade no seu cluster:
-
config.yaml: O arquivo de configuração do cluster RKE2 e K3s. -
rke2.yamlouk3s.yaml: O arquivo Kubeconfig para seu cluster RKE2 ou K3s. Este arquivo contém credenciais para acesso total ao cluster. Você pode usar este arquivo para se autenticar em um cluster Kubernetes iniciado pelo Rancher se o Rancher ficar fora do ar.
Para mais informações sobre como se conectar a um cluster sem o proxy de autenticação do Rancher e outras opções de configuração, consulte a documentação do arquivo kubeconfig.
Ferramentas para Provisionamento de Clusters Kubernetes
As ferramentas que o Rancher usa para provisionar clusters de usuários descendentes dependem do tipo de cluster que está sendo provisionado.
Kubernetes Iniciado pelo Rancher para Nós Hospedados em um Provedor de Infraestrutura
O Rancher pode provisionar dinamicamente nós em um provedor como Amazon EC2, DigitalOcean, Azure ou vSphere, e então instalar o Kubernetes neles.
O Rancher provisiona esse tipo de cluster usando docker-machine.
Kubernetes Iniciado pelo Rancher para Nós Personalizados
Ao configurar esse tipo de cluster, o Rancher instala o Kubernetes em nós existentes, o que cria um cluster personalizado.
Provedores de Kubernetes hospedados
Ao configurar esse tipo de cluster, o Kubernetes é instalado por provedores como Google Kubernetes Engine, Amazon Elastic Container Service for Kubernetes ou Azure Kubernetes Service.
O Rancher provisiona esse tipo de cluster usando kontainer-engine.
Componentes do Servidor Rancher e Código-fonte
Este diagrama mostra cada componente do qual o servidor Rancher é composto:
Os repositórios do GitHub para o Rancher podem ser encontrados nos seguintes links:
-
Norman, framework da API do Rancher
Esta é uma lista parcial dos repositórios mais importantes do Rancher. Para mais detalhes sobre o código-fonte do Rancher, consulte a seção sobre contribuindo para o Rancher. Para ver todas as bibliotecas e projetos usados no Rancher, veja o go.mod arquivo no repositório rancher/rancher.