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.

SUSE Rancher Prime Melhores Práticas de Segurança

Restringir Acesso Público aos Caminhos /version e /rancherversion

A instância do Rancher (local) upstream fornece informações sobre a versão do Rancher que está em execução e a versão do Go que foi usada para construí-la. Essas informações são acessíveis através do caminho /version, que é utilizado para tarefas como automatizar atualizações de versão ou confirmar que uma implantação foi bem-sucedida. A instância upstream também fornece informações sobre a versão do Rancher acessíveis através do caminho /rancherversion.

Adversários podem abusar dessas informações para identificar a versão do Rancher em execução e correlacioná-la com possíveis bugs a serem explorados. Se sua instância do Rancher upstream estiver disponível publicamente na web, use um gateway de segurança de Camada 7 para bloquear /version e /rancherversion.

Veja OWASP Teste de Segurança de Aplicações Web - Enumerar Interfaces de Administração de Infraestrutura e Aplicação para mais informações sobre como proteger seu servidor.

Gerenciamento de sessão

Alguns ambientes podem exigir controles de segurança adicionais para gerenciamento de sessões. Por exemplo, você pode querer limitar as sessões ativas simultâneas dos usuários ou restringir de quais geolocalizações essas sessões podem ser iniciadas. Esses recursos não são suportados pelo Rancher por padrão.

Se você precisar de tais recursos, combine gateways de segurança de Camada 7 com provedores de autenticação externa.

Use Balanceadores de Carga Externos para Proteger Portas Vulneráveis

Você deve proteger as seguintes portas atrás de um balanceador de carga externo que tenha offload de SSL habilitado:

  • K3s: Porta 6443, usada pela API do Kubernetes.

  • RKE2: Porta 6443, usada pela API do Kubernetes, e porta 9345, usada para registro de nós.

Essas portas possuem certificados TLS SAN que listam os endereços IP públicos dos nós. Um atacante poderia usar essas informações para obter acesso não autorizado ou monitorar a atividade no cluster. Proteger essas portas ajuda a mitigar a divulgação dos endereços IP públicos dos nós para potenciais atacantes.

Política de Nome de Usuário do Rancher

Por padrão, o Kubernetes não fornece mecanismos de aplicação para políticas básicas de nome de usuário. No Rancher, isso significa que qualquer aplicação de formatos de nome de usuário, convenções de nomenclatura ou políticas básicas deve ser tratada pelas políticas do provedor de identidade externo, se tais políticas estiverem em vigor.

No Rancher, admin é o nome de usuário padrão para o usuário administrador, conforme destacado aqui

Exemplos de políticas básicas potenciais incluem:

  • Exigir que os nomes de usuário sigam uma convenção organizacional (por exemplo, firstname.lastname)

  • Impor requisitos de comprimento mínimo ou máximo

  • Proibir certos caracteres especiais

  • Prevenir a usurpação de identidade proibindo nomes reservados (por exemplo, admin, root)

Sem esses controles na camada do provedor de identidade, há um risco de práticas de nome de usuário inconsistentes ou inseguras, o que pode complicar auditorias de acesso e levar a tentativas de escalonamento de privilégios.

Atualmente, o Rancher aplica apenas um comprimento mínimo de senha.

Recomendação: Recomendamos fortemente que os clientes:

  • Revejam e configurem políticas básicas de nome de usuário diretamente em seus provedores de identidade externos (por exemplo, LDAP, Active Directory, SAML ou OIDC).

  • Assegurem que essas políticas estejam alinhadas com os requisitos de segurança e conformidade da organização.

  • Auditem regularmente as contas de usuário para detectar inconsistências de nomenclatura ou violações de políticas.

Para obter mais informações, consulte:

Regras WAF

O Rancher é projetado para suportar uma ampla gama de cenários de implantação, incluindo ambientes onde os clientes podem automatizar programaticamente a criação ou o provisionamento de um grande número de clusters. Impor limites rigorosos em nível de aplicação dentro do próprio Rancher poderia interferir em cargas de trabalho legítimas que requerem escalonamento dinâmico.

Por exemplo:

  • Pipelines de CI/CD podem criar e desmontar clusters com frequência.

  • Portais de autoatendimento poderiam provisionar clusters sob demanda para desenvolvedores.

  • Ambientes de teste podem gerar altos volumes de chamadas de API.

Risco: Sem a limitação de taxa apropriada, adversários poderiam explorar endpoints não autenticados ou autenticados para:

  • Esgotar recursos (Negação de Serviço).

  • Inflar custos de armazenamento.

  • Degradar o desempenho para usuários legítimos.

Recomendação: A maneira mais eficaz de mitigar esse risco é implementar limitação de taxa e proteção contra abusos na infraestrutura ou na camada do gateway de segurança de Aplicação Web (WAF). Essa abordagem permite que os limites sejam ajustados para o uso esperado e as características de escalonamento de cada ambiente. Alguns exemplos de controles podem ser:

  • Configurar um gateway de segurança de Aplicação Web ou Gateway de API para impor limites de taxa em operações sensíveis, como criação e provisionamento de clusters.

  • Definir limites com base nas expectativas de carga de trabalho de referência (por exemplo, o número máximo de solicitações por minuto por cliente).

  • Monitorar logs e alertar sobre anomalias para detectar possíveis abusos.

  • Aplicar uma cota de recursos, que é um recurso do Rancher que limita os recursos disponíveis para um projeto ou namespace.

Para obter mais informações, consulte:

Política de Nome de Usuário do Rancher

Por padrão, o Kubernetes não fornece mecanismos de aplicação para políticas básicas de nome de usuário. No Rancher, isso significa que qualquer aplicação de formatos de nome de usuário, convenções de nomenclatura ou políticas básicas deve ser tratada pelas políticas do provedor de identidade externo, se tais políticas estiverem em vigor.

No Rancher, admin é o nome de usuário padrão para o usuário administrador, conforme destacado aqui

Exemplos de políticas básicas potenciais incluem:

  • Exigir que os nomes de usuário sigam uma convenção organizacional (por exemplo, firstname.lastname)

  • Impor requisitos de comprimento mínimo ou máximo

  • Proibir certos caracteres especiais

  • Prevenir a usurpação de identidade proibindo nomes reservados (por exemplo, admin, root)

Sem esses controles na camada do provedor de identidade, há um risco de práticas de nome de usuário inconsistentes ou inseguras, o que pode complicar auditorias de acesso e levar a tentativas de escalonamento de privilégios.

Atualmente, o Rancher aplica apenas um comprimento mínimo de senha.

Recomendação: Recomendamos fortemente que os clientes:

  • Revejam e configurem políticas básicas de nome de usuário diretamente em seus provedores de identidade externos (por exemplo, LDAP, Active Directory, SAML ou OIDC).

  • Assegurem que essas políticas estejam alinhadas com os requisitos de segurança e conformidade da organização.

  • Auditem regularmente as contas de usuário para detectar inconsistências de nomenclatura ou violações de políticas.

Para obter mais informações, consulte:

Regras WAF

O Rancher é projetado para suportar uma ampla gama de cenários de implantação, incluindo ambientes onde os clientes podem automatizar programaticamente a criação ou o provisionamento de um grande número de clusters. Impor limites rigorosos em nível de aplicação dentro do próprio Rancher poderia interferir em cargas de trabalho legítimas que requerem escalonamento dinâmico.

Por exemplo:

  • Pipelines de CI/CD podem criar e desmontar clusters com frequência.

  • Portais de autoatendimento poderiam provisionar clusters sob demanda para desenvolvedores.

  • Ambientes de teste podem gerar altos volumes de chamadas de API.

Risco: Sem a limitação de taxa apropriada, adversários poderiam explorar endpoints não autenticados ou autenticados para:

  • Esgotar recursos (Negação de Serviço).

  • Inflar custos de armazenamento.

  • Degradar o desempenho para usuários legítimos.

Recomendação: A maneira mais eficaz de mitigar esse risco é implementar limitação de taxa e proteção contra abusos na infraestrutura ou na camada do gateway de segurança de Aplicação Web (WAF). Essa abordagem permite que os limites sejam ajustados para o uso esperado e as características de escalonamento de cada ambiente. Alguns exemplos de controles podem ser:

  • Configurar um gateway de segurança de Aplicação Web ou Gateway de API para impor limites de taxa em operações sensíveis, como criação e provisionamento de clusters.

  • Definir limites com base nas expectativas de carga de trabalho de referência (por exemplo, o número máximo de solicitações por minuto por cliente).

  • Monitorar logs e alertar sobre anomalias para detectar possíveis abusos.

  • Aplicar uma cota de recursos, que é um recurso do Rancher que limita os recursos disponíveis para um projeto ou namespace.

Para obter mais informações, consulte: