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 reduzir 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](runtime-security.md). ## 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](https://github.com/bottlerocket-os/bottlerocket/) 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 o SELinux. Como alternativa, use a [AMI otimizada para EKS](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-amis.html) 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](https://github.com/aws-samples/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 AMIs personalizadas EKS compatíveis com STIG. ### 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 as AMIs otimizadas para EKS, é uma prática recomendada manter essas imagens do sistema operacional hospedeiro atualizadas com os patches de segurança mais recentes. Para as AMIs otimizadas para EKS, verifique regularmente o [canal de notas de and/or versão](https://github.com/awslabs/amazon-eks-ami/releases) do [CHANGELOG](https://github.com/awslabs/amazon-eks-ami/blob/master/CHANGELOG.md) 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](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) do EKS usam a primeira abordagem e exibirão uma mensagem no console para atualizar seus trabalhadores quando uma nova AMI estiver disponível. `eksctl`també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](https://www.cisecurity.org/benchmark/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](https://github.com/aquasecurity/kube-bench) em um cluster EKS, siga [estas instruções](https://github.com/aquasecurity/kube-bench/blob/main/docs/running.md#running-cis-benchmark-in-an-eks-cluster) do Aqua Security. Para obter mais informações, consulte [Apresentando o CIS Amazon EKS](https://aws.amazon.com/blogs/containers/introducing-cis-amazon-eks-benchmark/) Benchmark. ### Minimize o acesso aos nós de trabalho Em vez de habilitar o acesso SSH, use o [SSM Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) 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, poderá instalar o agente SSM com um, DaemonSet como [neste](https://github.com/aws-samples/ssm-agent-daemonset-installer) 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 querendo 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](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-install-plugin.html) instalado, você pode então executar ``` aws ssm start-session --target [INSTANCE_ID_OF_EKS_NODE] ``` para acessar o nó. **nota** Você também pode considerar a adição de permissões para [ativar o registro no Gerenciador de Sessões](https://docs.aws.amazon.com/systems-manager/latest/userguide/getting-started-create-iam-instance-profile.html#create-iam-instance-profile-ssn-logging). ### 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](https://docs.aws.amazon.com/inspector/latest/user/what-is-inspector.html) 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 AMIs](https://docs.aws.amazon.com/systems-manager/latest/userguide/ami-preinstalled-agent.html) [Amazon Linux otimizadas para EKS](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html). Independentemente do status do agente SSM, todas as suas instâncias do Amazon EC2 são verificadas 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](https://docs.aws.amazon.com/inspector/latest/user/enable-disable-scanning-ec2.html). **Importante** O Inspector não pode ser executado na infraestrutura usada para executar os pods do Fargate. ## Alternativas ### Execute o SELinux **nota** Disponível no Red Hat Enterprise Linux (RHEL), CentOS, Bottlerocket e Amazon Linux 2023 O SELinux fornece uma camada adicional de segurança para manter os contêineres isolados uns dos outros e do host. O 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, o SELinux pode ser usado para impedir que os contêineres acessem os recursos uns dos outros. As políticas do contêiner SELinux são definidas no pacote [container-selinux](https://github.com/containers/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 para`svirt_lxc_net_t`. Essas políticas impedem efetivamente que os contêineres acessem determinados recursos do host. Quando você configura o SELinux para 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, que concede a um contêiner permissões para áreas específicas do sistema de arquivos. Isso é semelhante aos PSPs, pois você pode criar perfis diferentes para diferentes. containers/pods 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. O SELinux for Containers tem um conjunto de opções que podem ser configuradas para modificar as restrições padrão. Os seguintes booleanos do SELinux podem ser ativados ou desativados de acordo com suas necessidades: | Booleano | Padrão | Description | | --- | --- | --- | | `container_connect_any` | `off` | Permita que os contêineres acessem portas privilegiadas no host. Por exemplo, se você tiver um contêiner que precise mapear portas para 443 ou 80 no host. | | `container_manage_cgroup` | `off` | Permita que os contêineres gerenciem a configuração do cgroup. Por exemplo, um contêiner executando o systemd precisará que isso seja habilitado. | | `container_use_cephfs` | `off` | Permita que os contêineres usem um sistema de arquivos ceph. | 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ótulo`container_var_lib_t`. Para ver uma lista completa dos rótulos padrão, consulte o arquivo [container.fc.](https://github.com/containers/container-selinux/blob/master/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. + `:z`rotulará novamente os arquivos para que o contêiner possa read/write + `:Z`rotulará novamente os arquivos para que **somente** o contêiner possa read/write ``` 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 uma política SELinux para permitir a leitura devar/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 [exemplos de AMIs para o Amazon EKS](https://github.com/aws-samples/amazon-eks-custom-amis) que têm o SELinux configurado no CentOS 7 e no RHEL 7. Essas AMIs foram desenvolvidas para demonstrar exemplos de implementações que atendem aos requisitos de clientes altamente regulamentados. **Atenção** O SELinux ignorará os contêineres em que o tipo não está confinado. ## Ferramentas e recursos + [SELinux Kubernetes RBAC e políticas de segurança de envio para aplicativos On-prem ](https://platform9.com/blog/selinux-kubernetes-rbac-and-shipping-security-policies-for-on-prem-applications/) + [Fortalecimento iterativo do Kubernetes](https://jayunit100.blogspot.com/2019/07/iterative-hardening-of-kubernetes-and.html) + [Auditoria 2 Permitir](https://linux.die.net/man/1/audit2allow) + [Alerta marítimo](https://linux.die.net/man/8/sealert) + [Gerar políticas SELinux para contêineres com o Udica](https://www.redhat.com/en/blog/generate-selinux-policies-containers-with-udica) descreve uma ferramenta que analisa os arquivos de especificações do contêiner para recursos, portas e pontos de montagem do Linux e gera um conjunto de regras SELinux que permitem que o contêiner seja executado corretamente. + Manuais do [AMI Hardening](https://github.com/aws-samples/amazon-eks-custom-amis#hardening) para fortalecer o sistema operacional para atender a diferentes requisitos regulatórios + [Keiko Upgrade Manager](https://github.com/keikoproj/upgrade-manager), um projeto de código aberto da Intuit que orquestra a rotação dos nós de trabalho. + [Sysdig Secure](https://sysdig.com/products/kubernetes-security/) + [eksctl](https://eksctl.io/)