As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Protegendo a infraestrutura (hosts)

Por mais que seja importante proteger suas imagens de contêiner, é igualmente importante proteger a infraestrutura que as executa. Esta seção explora maneiras diferentes de mitigar os riscos de ataques lançados diretamente contra o host. Essas diretrizes devem ser usadas em conjunto com as descritas na seção Runtime Security.

Recomendações

Use um sistema operacional otimizado para executar contêineres

Considere usar o Flatcar Linux, o Project Atomic, o RancherOS e o Bottlerocket, um sistema operacional especial da AWS projetado para executar contêineres Linux. Ele inclui uma superfície de ataque reduzida, uma imagem de disco que é verificada na inicialização e limites de permissão impostos usando SELinux.

Como alternativa, use a AMI otimizada para EKS para seus nós de trabalho do Kubernetes. A AMI otimizada para EKS é lançada regularmente e contém um conjunto mínimo de pacotes de sistema operacional e binários necessários para executar suas cargas de trabalho em contêineres.

Consulte a especificação de compilação do Amazon EKS AMI RHEL para obter um exemplo de script de configuração que pode ser usado para criar uma AMI personalizada do Amazon EKS em execução no Red Hat Enterprise Linux usando o Hashicorp Packer. Esse script pode ser ainda mais aproveitado para criar um EKS personalizado compatível com STIG. AMIs

Mantenha o sistema operacional do seu node de trabalho atualizado

Independentemente de você usar um sistema operacional host otimizado para contêineres, como o Bottlerocket, ou um Amazon Machine Image maior, mas ainda minimalista, como o EKS AMIs, é uma prática recomendada manter essas imagens do sistema operacional hospedeiro atualizadas com os patches de segurança mais recentes.

Para otimizar o EKS AMIs, verifique regularmente o canal CHANGELOG e/ou as notas de versão e automatize a implantação de imagens atualizadas de nós de trabalho em seu cluster.

Trate sua infraestrutura como imutável e automatize a substituição de seus nós de trabalho

Em vez de realizar atualizações no local, substitua seus trabalhadores quando um novo patch ou atualização estiver disponível. Isso pode ser abordado de duas maneiras. Você pode adicionar instâncias a um grupo de escalonamento automático existente usando a AMI mais recente ao isolar e drenar os nós sequencialmente até que todos os nós do grupo sejam substituídos pela AMI mais recente. Como alternativa, você pode adicionar instâncias a um novo grupo de nós enquanto isola e drena sequencialmente os nós do grupo de nós antigo até que todos sejam substituídos. Os grupos de nós gerenciados do EKS usam a primeira abordagem e exibirão uma mensagem no console para atualizar seus trabalhadores quando uma nova AMI estiver disponível. eksctltambém tem um mecanismo para criar grupos de nós com a AMI mais recente e para isolar e drenar facilmente os pods dos grupos de nós antes que as instâncias sejam encerradas. Se você decidir usar um método diferente para substituir seus nós de trabalho, é altamente recomendável automatizar o processo para minimizar a supervisão humana, pois provavelmente precisará substituir trabalhadores regularmente à medida que novos updates/patches forem lançados e quando o plano de controle for atualizado.

Com o EKS Fargate, a AWS atualizará automaticamente a infraestrutura subjacente à medida que as atualizações forem disponibilizadas. Muitas vezes, isso pode ser feito sem problemas, mas pode haver momentos em que uma atualização faça com que seu pod seja reprogramado. Portanto, recomendamos que você crie implantações com várias réplicas ao executar seu aplicativo como um pod Fargate.

Execute periodicamente o kube-bench para verificar a conformidade com os benchmarks do CIS para Kubernetes

O kube-bench é um projeto de código aberto da Aqua que avalia seu cluster em relação aos benchmarks do CIS para Kubernetes. O benchmark descreve as melhores práticas para proteger clusters Kubernetes não gerenciados. O CIS Kubernetes Benchmark abrange o plano de controle e o plano de dados. Como o Amazon EKS fornece um plano de controle totalmente gerenciado, nem todas as recomendações do CIS Kubernetes Benchmark são aplicáveis. Para garantir que esse escopo reflita como o Amazon EKS é implementado, a AWS criou o CIS Amazon EKS Benchmark. O benchmark EKS é herdado do CIS Kubernetes Benchmark com informações adicionais da comunidade com considerações de configuração específicas para clusters EKS.

Ao executar o kube-bench em um cluster EKS, siga estas instruções do Aqua Security. Para obter mais informações, consulte Apresentando o CIS Amazon EKS Benchmark.

Minimize o acesso aos nós de trabalho

Em vez de habilitar o acesso SSH, use o SSM Session Manager quando precisar se conectar remotamente a um host. Ao contrário das chaves SSH que podem ser perdidas, copiadas ou compartilhadas, o Session Manager permite que você controle o acesso às instâncias do EC2 usando o IAM. Além disso, ele fornece uma trilha de auditoria e um registro dos comandos que foram executados na instância.

A partir de 19 de agosto de 2020, os grupos de nós gerenciados oferecem suporte a AMIs e modelos de lançamento do EC2 personalizados. Isso permite que você incorpore o agente SSM na AMI ou o instale enquanto o nó de trabalho está sendo inicializado. Se você preferir não modificar a AMI otimizada ou o modelo de execução do ASG, você pode instalar o agente SSM com um, DaemonSet como neste exemplo.

Política mínima de IAM para acesso SSH baseado em SSM

A política gerenciada pela AmazonSSMManagedInstanceCore AWS contém várias permissões que não são necessárias para o SSM Session Manager /SSM RunCommand se você estiver apenas tentando evitar o acesso ao SSH. Especificamente, são preocupantes as * permissões ssm:GetParameter(s) que permitiriam que a função acessasse todos os parâmetros no Parameter Store (inclusive SecureStrings com a chave KMS gerenciada pela AWS configurada).

A política do IAM a seguir contém o conjunto mínimo de permissões para permitir o acesso ao nó por meio do SSM Systems Manager.

{
  "Version":"2012-10-17",
  "Statement": [
    {
      "Sid": "EnableAccessViaSSMSessionManager",
      "Effect": "Allow",
      "Action": [
        "ssmmessages:OpenDataChannel",
        "ssmmessages:OpenControlChannel",
        "ssmmessages:CreateDataChannel",
        "ssmmessages:CreateControlChannel",
        "ssm:UpdateInstanceInformation"
      ],
      "Resource": "*"
    },
    {
      "Sid": "EnableSSMRunCommand",
      "Effect": "Allow",
      "Action": [
        "ssm:UpdateInstanceInformation",
        "ec2messages:SendReply",
        "ec2messages:GetMessages",
        "ec2messages:GetEndpoint",
        "ec2messages:FailMessage",
        "ec2messages:DeleteMessage",
        "ec2messages:AcknowledgeMessage"
      ],
      "Resource": "*"
    }
  ]
}

Com essa política em vigor e o plug-in do Gerenciador de Sessões instalado, você pode então executar

aws ssm start-session --target [INSTANCE_ID_OF_EKS_NODE]

para acessar o nó.

Implante trabalhadores em sub-redes privadas

Ao implantar trabalhadores em sub-redes privadas, você minimiza a exposição deles à Internet, onde os ataques geralmente se originam. A partir de 22 de abril de 2020, a atribuição de endereços IP públicos aos nós em grupos de nós gerenciados será controlada pela sub-rede na qual eles serão implantados. Antes disso, os nós em um grupo de nós gerenciados recebiam automaticamente um IP público. Se você optar por implantar seus nós de trabalho em sub-redes públicas, implemente regras restritivas de grupos de segurança da AWS para limitar sua exposição.

Execute o Amazon Inspector para avaliar os anfitriões quanto à exposição, vulnerabilidades e desvios das melhores práticas

Você pode usar o Amazon Inspector para verificar se há acesso não intencional à rede aos seus nós e vulnerabilidades nas instâncias subjacentes do Amazon EC2.

O Amazon Inspector pode fornecer dados comuns de vulnerabilidades e exposições (CVE) para suas instâncias do Amazon EC2 somente se o agente do Amazon EC2 Systems Manager (SSM) estiver instalado e habilitado. Esse agente está pré-instalado em várias Amazon Machine Images (AMIs), incluindo Amazon Linux AMIs otimizado para EKS. Independentemente do status do agente SSM, todas as suas instâncias do Amazon EC2 são escaneadas em busca de problemas de acessibilidade da rede. Para obter mais informações sobre a configuração de escaneamentos para o Amazon EC2, consulte Verificando instâncias do Amazon EC2.

Alternativas

Corra SELinux

SELinux fornece uma camada adicional de segurança para manter os contêineres isolados uns dos outros e do host. SELinux permite que os administradores apliquem controles de acesso obrigatórios (MAC) para cada usuário, aplicativo, processo e arquivo. Pense nisso como um backstop que restringe as operações que podem ser executadas a recursos específicos com base em um conjunto de rótulos. No EKS, SELinux pode ser usado para impedir que os contêineres acessem os recursos uns dos outros.

As SELinux políticas de contêiner são definidas no pacote container-selinux. O Docker CE requer esse pacote (junto com suas dependências) para que os processos e arquivos criados pelo Docker (ou outros tempos de execução de contêineres) sejam executados com acesso limitado ao sistema. Os contêineres utilizam o container_t rótulo, que é um alias parasvirt_lxc_net_t. Essas políticas impedem efetivamente que os contêineres acessem determinados recursos do host.

Quando você configura SELinux para o Docker, o Docker rotula automaticamente as cargas de trabalho container_t como um tipo e dá a cada contêiner um nível MCS exclusivo. Isso isolará os contêineres uns dos outros. Se precisar de restrições mais flexíveis, você pode criar seu próprio perfil no SElinux qual concede permissões a um contêiner para áreas específicas do sistema de arquivos. Isso é semelhante ao fato PSPs de que você pode criar perfis diferentes para diferentes contêineres/cápsulas. Por exemplo, você pode ter um perfil para cargas de trabalho gerais com um conjunto de controles restritivos e outro para coisas que exigem acesso privilegiado.

SELinux for Containers tem um conjunto de opções que podem ser configuradas para modificar as restrições padrão. Os seguintes SELinux booleanos podem ser ativados ou desativados de acordo com suas necessidades:

Por padrão, os contêineres podem read/execute subtrair /usr e ler a maior parte do conteúdo/etc. Os arquivos abaixo /var/lib/docker e /var/lib/containers têm o rótulocontainer_var_lib_t. Para ver uma lista completa dos rótulos padrão, consulte o arquivo container.fc.

docker container run -it \
  -v /var/lib/docker/image/overlay2/repositories.json:/host/repositories.json \
  centos:7 cat /host/repositories.json
# cat: /host/repositories.json: Permission denied

docker container run -it \
  -v /etc/passwd:/host/etc/passwd \
  centos:7 cat /host/etc/passwd
# cat: /host/etc/passwd: Permission denied

Os arquivos marcados com container_file_t são os únicos arquivos que podem ser gravados por contêineres. Se você quiser que uma montagem de volume seja gravável, você precisará especificar :z ou :Z no final.

ls -Z /var/lib/misc
# -rw-r--r--. root root system_u:object_r:var_lib_t:s0   postfix.aliasesdb-stamp

docker container run -it \
  -v /var/lib/misc:/host/var/lib/misc:z \
  centos:7 echo "Relabeled!"

ls -Z /var/lib/misc
#-rw-r--r--. root root system_u:object_r:container_file_t:s0 postfix.aliasesdb-stamp

docker container run -it \
  -v /var/log:/host/var/log:Z \
  fluentbit:latest

No Kubernetes, a renomeação é um pouco diferente. Em vez de fazer com que o Docker renomeie automaticamente os arquivos, você pode especificar um rótulo MCS personalizado para executar o pod. Os volumes que suportam a nova rotulagem serão automaticamente renomeados para que possam ser acessados. Os pods com uma etiqueta MCS correspondente poderão acessar o volume. Se você precisar de isolamento estrito, defina um rótulo MCS diferente para cada pod.

securityContext:
  seLinuxOptions:
    # Provide a unique MCS label per container
    # You can specify user, role, and type also
    # enforcement based on type and level (svert)
    level: s0:c144:c154

Neste exemplo, s0:c144:c154 corresponde a um rótulo MCS atribuído a um arquivo que o contêiner tem permissão para acessar.

No EKS, você pode criar políticas que permitam a execução de contêineres privilegiados, como o FluentD, e criar SELinux uma política para permitir a leitura de /var/log no host sem precisar renomear o diretório do host. Pods com o mesmo rótulo poderão acessar os mesmos volumes do host.

Implementamos uma amostra AMIs para o Amazon EKS que foi SELinux configurada no CentOS 7 e no RHEL 7. Eles AMIs foram desenvolvidos para demonstrar exemplos de implementações que atendem aos requisitos de clientes altamente regulamentados.

Ferramentas e recursos