Melhores práticas de segurança

Melhores Práticas: Nível de exposição do plano

Recomendamos que você responda às seguintes perguntas antes de implementar um plano de segurança para os clusters criados com o Kubernetes Engine:

• Quanta exposição à internet você deseja que os clusters tenham?
• Como você planeja expor cargas de trabalho internamente à sua VCN e/ou externamente à internet?
• Como você planeja dimensionar cargas de trabalho?
• Quais tipos de serviços Oracle o cluster consumirá?

Depois de responder às perguntas anteriores, recomendamos que você considere as seguintes melhores práticas:

• Melhores Práticas: Criar clusters privados

  Recomendamos que, se você quiser expor apenas cargas de trabalho internamente à sua VCN e não à internet, crie clusters nativos da VCN, com o ponto final da API do Kubernetes em uma sub-rede privada. Esses clusters são às vezes chamados de clusters privados.

  Quando você configura clusters privados, todos os componentes do plano de controle (incluindo o ponto final da API do Kubernetes do cluster) estão em um espaço de rede privado RFC 1918. Como resultado, o acesso é limitado e todo o tráfego permanece nas redes da Oracle. Você pode bloquear o acesso à API do Kubernetes para uma VCN específica.

  Se você não usar clusters privados, o ponto final da API do Kubernetes do cluster terá um endereço IPv4 público e todo o tráfego para a API (incluindo o tráfego dos pools de nós do cluster) passará pelo espaço de rede pública.

  Consulte Anúncio de clusters privados do Kubernetes.

• Melhores Práticas: Coloque todos os aplicativos em sub-redes privadas

  Recomendamos que, se você quiser reduzir a exposição de um serviço à internet, coloque instâncias de computação de nó de trabalho executando cargas de trabalho de aplicativos em sub-redes privadas e configure balanceadores de carga para acessá-las.

  O isolamento de instâncias de serviço da Internet reduz a superfície de ataque de um serviço. A maioria das instâncias de serviço não precisa de exposição direta à internet.

  Consulte Configuração do Recurso de Rede para Criação e Implantação de Cluster.

• Melhores Práticas: Restringir o tráfego do cluster usando Grupos de Segurança de Rede

  Recomendamos que você defina regras de segurança em grupos de segurança de rede (em vez de em listas de segurança) para a VCN na qual deseja criar e implantar clusters.

  O Kubernetes Engine cria regras de segurança necessárias por padrão, mas você pode alterá-las para atender aos seus requisitos específicos.

  Consulte Configuração da Regra de Segurança em Grupos de Segurança de Rede e/ou Listas de Segurança.

Melhores Práticas: Aplique patches de segurança regularmente

Recomendamos que você atualize regularmente o sistema operacional em execução nos nós de trabalho para aplicar os patches de segurança mais recentes.

Os nós de trabalho em clusters criados pelo Kubernetes Engine executam uma imagem do Linux reforçada.

É importante manter o sistema operacional do nó de trabalho protegido e protegido porque os serviços executados nos nós de trabalho incluem o runtime do contêiner, o kubelet e o kube-proxy.

Outra boa prática é usar o benchmark do Kubernetes do CIS (Center for Internet Security) para nós de trabalho.

Consulte Criando Nós de Trabalho com Propriedades Atualizadas.

Melhores Práticas: Use uma combinação de políticas de rede do Kubernetes e grupos de segurança de rede (NSGs)

Recomendamos que você considere implementar políticas de rede do Kubernetes em combinação com grupos de segurança de rede do OCI (recomendado) e/ou listas de segurança.

Uma combinação de políticas de rede do Kubernetes (para proteger a comunicação de rede no nível do pod) e NSGs e/ou listas de segurança do OCI (para proteger a comunicação de rede no nível do host) pode oferecer a melhor postura de segurança de rede.

Consulte Segurança de Rede.

Melhores Práticas: Use grupos de segurança de rede (NSGs) em conjunto com ferramentas de infraestrutura como código (como Terraform)

Recomendamos o uso de regras de segurança em grupos de segurança de rede (NSGs), em vez de em listas de segurança, ao implementar um controlador de balanceamento de carga em conjunto com ferramentas de infraestrutura como código, como o Terraform,

Para operar o Kubernetes em escala, você geralmente usará ferramentas de infraestrutura como código, como o Terraform, para rastrear o estado dos recursos de infraestrutura. Por exemplo, para manter a infraestrutura em seu estado original e pretendido, você normalmente executará e executará novamente uma configuração do Terraform. No entanto, um conflito potencial surge para serviços do Kubernetes do tipo LoadBalancer se o cloud-controller-manager adicionar ou atualizar regras de segurança na lista de segurança que uma sub-rede usa. As alterações nas regras de segurança em uma lista de segurança não são refletidas na configuração do Terraform. Como resultado, na próxima vez que você executar o Terraform, as alterações nas regras de segurança na lista de segurança serão sinalizadas como uma "deriva" do estado original e serão descartadas quando você aplicar a configuração do Terraform. Sem as regras de segurança, os aplicativos implantados em um cluster podem falhar porque o balanceador de carga ou o balanceador de carga de rede que provisiona o serviço do tipo LoadBalancer não pode atender ao tráfego nem se comunicar com nós que hospedam os pods de aplicativo.

Você pode configurar o cloud-controller-manager para não gerenciar as regras de segurança na lista de segurança de uma sub-rede ou para gerenciar apenas regras de segurança de saída para o balanceador de carga ou o balanceador de carga de rede. No entanto, em ambos os casos, você precisa configurar manualmente as portas selecionadas toda vez que um novo serviço for implantado no cluster ou abrir completamente o intervalo de portas do nó. Nenhuma das soluções é ideal, pois uma envolve trabalho manual em tempo de execução e a outra introduz uma vulnerabilidade de segurança potencial.

Para evitar a possibilidade de o cloud-controller-manager alterar um recurso da lista de segurança adicionando ou atualizando regras de segurança, e essas alterações sendo subsequentemente descartadas quando você aplicar uma configuração do Terraform, recomendamos, portanto, que o cloud-controller-manager use NSGs. As regras de segurança definidas para um NSG são recursos por si só com seus próprios OCIDs e são independentes do próprio NSG. Como a alteração das regras de segurança do NSG não altera o próprio recurso do NSG, nenhuma alteração é descartada quando você aplica uma configuração do Terraform.

Para obter mais informações, consulte Usando a anotação oci.oraclecloud.com/security-rule-management-mode para gerenciar regras de segurança em NSGs e listas de segurança.

Melhores Práticas: Girar segredos e certificados regularmente

Recomendamos que você defina vidas curtas para segredos, credenciais e certificados e automatize sua rotação.

Melhores Práticas: Execute todos os aplicativos como um usuário não privilegiado

Recomendamos que você execute todos os aplicativos como um usuário não privilegiado. Este é também um requisito em uma série de normas regulamentares.

A execução de aplicativos como um usuário não privilegiado garante que, se um invasor explorar uma vulnerabilidade (como uma vulnerabilidade de execução remota de código), eles sejam restritos ao acesso limitado concedido ao usuário não privilegiado. O invasor também achará mais difícil escalar um ataque para obter privilégios adicionais, sair de um contêiner ou obter acesso root por meio de um bug do kernel.

Prática recomendada: Trate os recipientes como imutáveis

Recomendamos que você defina sistemas de arquivos raiz contêiner como somente leitura. Se você permitir que bibliotecas e binários no sistema de arquivos raiz de um contêiner sejam atualizados, tornará todo o cluster vulnerável a ataques.

A natureza efêmera dos contêineres oferece benefícios significativos de segurança. À medida que os aplicativos e seu ambiente imediato são implantados e atualizados como um todo, os ataques persistentes ao sistema geral são mais difíceis. A prevenção da modificação do sistema de arquivos raiz fortalece a segurança, reduzindo a probabilidade de ameaças e reduzindo seu impacto potencial.

Melhores Práticas: Considere descarregar o processamento SSL para controladores de entrada ou balanceadores de carga (se permitido)

Recomendamos que, se a política de segurança de rede da sua organização oferecer flexibilidade para isso, você transfira o processamento SSL para controladores de entrada ou balanceadores de carga.

Os controladores de entrada (por exemplo, Traefik, NGINX Open Source) permitem que você roteie de forma inteligente o tráfego HTTP/S que emana de fora do cluster para serviços em execução dentro do cluster. O serviço Oracle Cloud Infrastructure Load Balancer tem suporte para protocolos de criptografia de transporte (SSL e TLS) para criptografar dados em trânsito.

O tráfego criptografado pode ser encerrado em diferentes lugares dentro da rede (por exemplo, no balanceador de carga, no recurso de entrada, no pod). Como e onde você encerra as conexões SSL são finalmente ditadas pela política de segurança de rede da sua organização. Por exemplo, se a política de segurança de rede da sua organização exigir criptografia de ponta a ponta, o tráfego precisará ser descriptografado no pod. A descriptografia do tráfego colocará uma carga adicional no pod porque o pod terá que gastar ciclos estabelecendo o handshake inicial, e o processamento SSL/TLS consome muita CPU. Consequentemente, se a política de segurança de rede da sua organização oferecer a flexibilidade para fazer isso, transfira o processamento SSL para o controlador de entrada ou o balanceador de carga.

Melhores Práticas de auditoria, registro em log e monitoramento

Recomendamos que você considere as seguintes práticas recomendadas ao ativar a auditoria, o registro em log e o monitoramento:

• Melhores Práticas: Verifique os logs regularmente

  Recomendamos que você verifique regularmente os logs de auditoria do Servidor de API do Kubernetes e os logs de aplicativos em execução nos nós de trabalho no cluster. Verificar os logs regularmente permite identificar ameaças ou vulnerabilidades no cluster.

  Consulte Observando Clusters do Kubernetes.

• Melhores Práticas: Ativar log de auditoria

  Recomendamos que você ative o log de auditoria e salve os logs de auditoria em um repositório seguro para análise futura no caso de comprometimento.

  Consulte Exibindo Logs do Kubernetes API Server Audit

• Melhores Práticas: Usar o log baseado em cluster do Kubernetes

  Recomendamos que você use o registro em log baseado em cluster do Kubernetes para registrar a atividade do contêiner em um subsistema de registro em log central. A saída padrão e a saída de erro padrão de cada contêiner em um cluster do Kubernetes podem ser ingeridas (usando um agente como o Fluentd em execução em cada nó) em ferramentas como Elasticsearch e exibidas com o Kibana.

  Consulte Arquitetura de Log na documentação do Kubernetes.

• Melhores Práticas: Monitorar componentes do cluster

  Recomendamos que você monitore contêineres, pods, aplicativos, serviços e outros componentes de cluster usando ferramentas como Prometheus, Grafana e Jaeger.

• Melhores Práticas: Registre metadados de tráfego de rede e analise-os regularmente

  Recomendamos que você ative os logs de fluxo da VCN no serviço Oracle Cloud Infrastructure Logging para capturar metadados sobre o tráfego que flui por meio de uma VCN, como endereço IP e porta de origem e destino, juntamente com pacotes aceitos/eliminados. Depois de capturá-lo, analise os metadados regularmente para identificar atividades suspeitas ou incomuns entre recursos dentro da VCN, inclusive entre pods. Consulte Monitoramento de Tráfego de Rede usando Logs de Fluxo da VCN da Oracle.

Consulte Observando Clusters do Kubernetes.

Melhores Práticas: Use imagens de contêiner pequenas e seguras

Recomendamos que você crie imagens de contêiner pequenas e seguras que contenham apenas os pacotes, bibliotecas e ferramentas exigidos pelo aplicativo do contêiner.

Um novo desenvolvedor muitas vezes comete o erro de usar a imagem base, mesmo que eles não precisem da maioria dos pacotes e bibliotecas na imagem base. Recomendamos a escolha de imagens menores que exijam menos espaço de armazenamento. Uma imagem menor ajuda a extrair e construir a imagem mais rapidamente. E com uma imagem menor, há menos probabilidade de problemas de segurança.

Para reduzir ainda mais o tamanho da imagem do contêiner, recomendamos que você instale apenas as ferramentas necessárias para o aplicativo do contêiner. Não inclua ferramentas de depuração em contêineres de produção.

Se os aplicativos precisarem apenas de ferramentas de rede no início do pod, em vez de colocar ferramentas exploráveis, como curl em uma imagem para aplicativos de longa execução, recomendamos que você considere o uso de contêineres de inicialização separados ou a entrega dos dados usando um método mais nativo do Kubernetes (como ConfigMaps).

Também recomendamos que você mantenha as imagens de contêiner atualizadas e procure novas versões da imagem base e de quaisquer ferramentas de terceiros instaladas.

Melhores Práticas: Limitar a exposição da credencial

Recomendamos que você não defina credenciais no código do aplicativo. Em vez disso, use um vault digital (como o Oracle Cloud Infrastructure Vault) para armazenar e recuperar chaves e credenciais digitais.

Melhores Práticas: Use um token de autenticação apropriado para acessar o cluster

Recomendamos que você só use o token de autenticação gerado pelo comando no arquivo kubeconfig de um cluster quando acessar o cluster com o kubectl e o Painel de Controle do Kubernetes. Quando outros processos e ferramentas acessarem o cluster, use um token de autenticação não específico do usuário para autenticação.

Quando você configura o arquivo kubeconfig para um cluster, por padrão, o arquivo contém um comando da CLI do Oracle Cloud Infrastructure para gerar um token de autenticação de curta duração, com escopo baseado no cluster e específico do usuário. O token de autenticação gerado pelo comando da CLI é apropriado para autenticar usuários individuais que acessam o cluster por meio do kubectl e do Painel de Controle do Kubernetes.

No entanto, o token de autenticação gerado não é apropriado para autenticar processos e ferramentas que acessam o cluster, como ferramentas de integração contínua e entrega contínua (CI/CD). Para garantir o acesso ao cluster, essas ferramentas requerem tokens de autenticação de longa duração e não específicos do usuário. Uma solução é usar uma conta de serviço do Kubernetes.

Consulte Adicionando um Token da Autenticação da Conta do Serviço a um Arquivo Kubeconfig.

Melhores Práticas: Configure o acesso com menos privilégios ao criar RoleBindings e ClusterRoleBindings

Recomendamos que você só defina RoleBindings e ClusterRoleBindings do Kubernetes que incluam o conjunto de permissões necessárias para executar uma função específica.

Por padrão, os usuários não recebem nenhuma atribuição (ou clusterrole) do Kubernetes RBAC. Portanto, antes de tentar criar uma nova atribuição (ou clusterrole), você deve ter recebido uma atribuição (ou clusterrole) privilegiada apropriada. Várias dessas atribuições e clusters são sempre criados por padrão, incluindo o cluster-admin (para obter uma lista completa, consulte Atribuições padrão e bindings de atribuição na documentação do Kubernetes). O cluster-admin clusterrole fornece essencialmente privilégios de superusuário. Um usuário que recebeu o cluster-admin clusterrole pode executar qualquer operação em todos os namespaces de um cluster específico.

Consulte Sobre o Controle de Acesso e o Kubernetes Engine (OKE).