Segurança de imagem - Amazon EKS
RecomendaçõesFerramentas e recursos

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á.

Segurança de imagem

Você deve considerar a imagem do contêiner como sua primeira linha de defesa contra um ataque. Uma imagem insegura e mal construída pode permitir que um invasor escape dos limites do contêiner e tenha acesso ao host. Uma vez no host, um invasor pode obter acesso a informações confidenciais ou se mover lateralmente dentro do cluster ou com sua conta da AWS. As melhores práticas a seguir ajudarão a mitigar o risco de isso acontecer.

Recomendações

Crie imagens mínimas

Comece removendo todos os binários estranhos da imagem do contêiner. Se você estiver usando uma imagem desconhecida do Dockerhub, inspecione a imagem usando um aplicativo como o Dive, que pode mostrar o conteúdo de cada uma das camadas do contêiner. Remova todos os binários com os bits SETUID e SETGID, pois eles podem ser usados para aumentar os privilégios e considere a remoção de todos os shells e utilitários, como nc e curl, que podem ser usados para fins nefastos. Você pode encontrar os arquivos com os bits SETUID e SETGID com o seguinte comando:

find / -perm /6000 -type f -exec ls -ld {} \;

Para remover as permissões especiais desses arquivos, adicione a seguinte diretiva à imagem do contêiner:

RUN find / -xdev -perm /6000 -type f -exec chmod a-s {} \; || true

Coloquialmente, isso é conhecido como desobstruir sua imagem.

Use compilações de vários estágios

Usar compilações de vários estágios é uma forma de criar imagens mínimas. Muitas vezes, compilações de vários estágios são usadas para automatizar partes do ciclo de integração contínua. Por exemplo, compilações de vários estágios podem ser usadas para lintar seu código-fonte ou realizar análises estáticas de código. Isso dá aos desenvolvedores a oportunidade de obter feedback quase imediato, em vez de esperar pela execução de um pipeline. As compilações de vários estágios são atraentes do ponto de vista da segurança porque permitem minimizar o tamanho da imagem final enviada ao seu registro de contêiner. Imagens de contêiner sem ferramentas de criação e outros binários estranhos melhoram sua postura de segurança ao reduzir a superfície de ataque da imagem. Para obter informações adicionais sobre compilações em vários estágios, consulte a documentação de compilações em vários estágios do Docker.

Crie uma lista de materiais de software (SBOMs) para sua imagem de contêiner

Uma “lista de materiais de software” (SBOM) é um inventário aninhado dos artefatos de software que compõem a imagem do seu contêiner. O SBOM é um alicerce fundamental na segurança de software e no gerenciamento de riscos da cadeia de suprimentos de software. A geração e o armazenamento de SBOMS em um repositório central e a verificação SBOMs de vulnerabilidades ajudam a resolver as seguintes preocupações:

  • Visibilidade: entenda quais componentes compõem a imagem do seu contêiner. O armazenamento em um repositório central permite que você seja auditado e verificado SBOMs a qualquer momento, mesmo após a implantação, para detectar e responder a novas vulnerabilidades, como vulnerabilidades de dia zero.

  • Verificação de proveniência: garantia de que as suposições existentes de onde e como um artefato se origina são verdadeiras e de que o artefato ou os metadados que o acompanham não foram adulterados durante os processos de construção ou entrega.

  • Confiabilidade: garantia de que um determinado artefato e seu conteúdo podem ser confiáveis para fazer o que se pretende fazer, ou seja, é adequado para uma finalidade. Isso envolve avaliar se o código é seguro de executar e tomar decisões informadas sobre os riscos associados à execução do código. A confiabilidade é garantida pela criação de um relatório atestado de execução do pipeline junto com o SBOM atestado e o relatório de digitalização CVE atestado para garantir aos consumidores da imagem que essa imagem foi de fato criada por meios seguros (pipeline) com componentes seguros.

  • Verificação de confiança de dependência: verificação recursiva da árvore de dependências de um artefato quanto à confiabilidade e proveniência dos artefatos que ele usa. O Drift in SBOMs pode ajudar a detectar atividades maliciosas, incluindo dependências não autorizadas e não confiáveis e tentativas de infiltração.

As seguintes ferramentas podem ser usadas para gerar o SBOM:

  • O Amazon Inspector pode ser usado para criar e exportar. SBOMs

  • O Syft da Anchore também pode ser usado para geração de SBOM. Para varreduras de vulnerabilidade mais rápidas, o SBOM gerado para uma imagem de contêiner pode ser usado como uma entrada para escanear. O SBOM e o relatório de digitalização são então atestados e anexados à imagem antes de enviá-la para um repositório central da OCI, como o Amazon ECR, para fins de revisão e auditoria.

Saiba mais sobre como proteger sua cadeia de suprimentos de software revisando o guia de melhores práticas da cadeia de suprimentos de software CNCF.

Examine imagens em busca de vulnerabilidades regularmente

Assim como suas contrapartes de máquinas virtuais, as imagens de contêiner podem conter binários e bibliotecas de aplicativos com vulnerabilidades ou desenvolver vulnerabilidades ao longo do tempo. A melhor maneira de se proteger contra ataques é verificar regularmente suas imagens com um verificador de imagens. As imagens armazenadas no Amazon ECR podem ser digitalizadas por push ou sob demanda (uma vez durante um período de 24 horas). Atualmente, o ECR suporta dois tipos de escaneamento: básico e aprimorado. A digitalização básica utiliza a Clair, uma solução de digitalização de imagens de código aberto, sem nenhum custo. O escaneamento aprimorado usa o Amazon Inspector para fornecer escaneamentos contínuos automáticos por um custo adicional. Depois que uma imagem é digitalizada, os resultados são registrados no fluxo de eventos para o ECR in. EventBridge Você também pode ver os resultados de uma verificação no console do ECR. Imagens com uma vulnerabilidade ALTA ou CRÍTICA devem ser excluídas ou reconstruídas. Se uma imagem que foi implantada desenvolver uma vulnerabilidade, ela deverá ser substituída assim que possível.

Saber onde as imagens com vulnerabilidades foram implantadas é essencial para manter seu ambiente seguro. Embora você mesmo possa criar uma solução de rastreamento de imagens, já existem várias ofertas comerciais que fornecem esse e outros recursos avançados prontos para uso, incluindo:

Um webhook de validação do Kubernetes também pode ser usado para validar se as imagens estão livres de vulnerabilidades críticas. Os webhooks de validação são invocados antes da API Kubernetes. Eles geralmente são usados para rejeitar solicitações que não estão em conformidade com os critérios de validação definidos no webhook. Esse é um exemplo de um webhook sem servidor que chama a API ECR describeImageScan Findings para determinar se um pod está obtendo uma imagem com vulnerabilidades críticas. Se forem encontradas vulnerabilidades, o pod será rejeitado e uma mensagem com a lista de será CVEs retornada como um evento.

Use atestados para validar a integridade do artefato

Um atestado é uma “declaração” assinada criptograficamente que afirma que algo - um “predicado”, por exemplo, uma execução de pipeline ou o SBOM ou o relatório de verificação de vulnerabilidade é verdadeiro sobre outra coisa - um “assunto”, ou seja, a imagem do contêiner.

Os atestados ajudam os usuários a validar se um artefato vem de uma fonte confiável na cadeia de suprimentos de software. Como exemplo, podemos usar uma imagem de contêiner sem conhecer todos os componentes ou dependências de software incluídos nessa imagem. No entanto, se confiarmos em tudo o que o produtor da imagem do contêiner diz sobre qual software está presente, podemos usar o atestado do produtor para confiar nesse artefato. Isso significa que podemos continuar usando o artefato com segurança em nosso fluxo de trabalho, em vez de termos feito a análise sozinhos.

Crie políticas do IAM para repositórios ECR

Atualmente, não é incomum que uma organização tenha várias equipes de desenvolvimento operando de forma independente em uma conta compartilhada da AWS. Se essas equipes não precisarem compartilhar ativos, talvez você queira criar um conjunto de políticas do IAM que restrinjam o acesso aos repositórios com os quais cada equipe pode interagir. Uma boa maneira de implementar isso é usando namespaces ECR. Os namespaces são uma forma de agrupar repositórios semelhantes. Por exemplo, todos os registros da equipe A podem ser prefaciados com a equipe a/, enquanto os da equipe B podem usar o prefixo equipe-b/. A política para restringir o acesso pode ter a seguinte aparência:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowPushPull",
      "Effect": "Allow",
      "Action": [
        "ecr:GetDownloadUrlForLayer",
        "ecr:BatchGetImage",
        "ecr:BatchCheckLayerAvailability",
        "ecr:PutImage",
        "ecr:InitiateLayerUpload",
        "ecr:UploadLayerPart",
        "ecr:CompleteLayerUpload"
      ],
      "Resource": [
        "arn:aws:ecr:<region>:<account_id>:repository/team-a/*"
      ]
    }
  ]
}

Considere o uso de endpoints privados ECR

A API ECR tem um endpoint público. Consequentemente, os registros ECR podem ser acessados pela Internet, desde que a solicitação tenha sido autenticada e autorizada pelo IAM. Para aqueles que precisam operar em um ambiente de área restrita em que o cluster VPC não tem um Internet Gateway (IGW), você pode configurar um endpoint privado para ECR. A criação de um endpoint privado permite que você acesse de forma privada a API ECR por meio de um endereço IP privado, em vez de rotear o tráfego pela Internet. Para obter informações adicionais sobre esse tópico, consulte VPC endpoints da interface Amazon ECR.

Implemente políticas de endpoint para ECR

A política de endpoint padrão permite o acesso a todos os repositórios ECR em uma região. Isso pode permitir que um invasor/insider exfiltre dados empacotando-os como uma imagem de contêiner e enviando-os para um registro em outra conta da AWS. A mitigação desse risco envolve a criação de uma política de endpoint que limita o acesso da API aos repositórios ECR. Por exemplo, a política a seguir permite que todos os princípios da AWS em sua conta executem todas as ações em seus e somente em seus repositórios ECR:

{
  "Statement": [
    {
      "Sid": "LimitECRAccess",
      "Principal": "*",
      "Action": "*",
      "Effect": "Allow",
      "Resource": "arn:aws:ecr:<region>:<account_id>:repository/*"
    }
  ]
}

Você pode aprimorar isso ainda mais definindo uma condição que use o novo PrincipalOrgID atributo, o que evitará enviar/extrair imagens por meio de um princípio do IAM que não faz parte da sua organização da AWS. Consulte, aws: PrincipalOrg ID para obter detalhes adicionais. Recomendamos aplicar a mesma política a ambos os endpoints com.amazonaws.<region>.ecr.dkr e com.amazonaws.<region>.ecr.api. Como o EKS extrai imagens para kube-proxy, coredns e aws-node do ECR, você precisará adicionar o ID da conta do registro, por exemplo, à lista de recursos na política de endpoint ou alterar a política 602401143452.dkr.ecr.us-west-2.amazonaws.com/ para permitir retiradas e restringir envios ao ID da sua conta. A tabela abaixo revela o mapeamento entre as contas da AWS de onde as imagens EKS são vendidas e a região do cluster.

Número da conta Região

602401143452

Todas as regiões comerciais, exceto as listadas abaixo

—

—

800184023465

ap-east-1 - Ásia-Pacífico (Hong Kong)

558608220178

me-south-1 - Oriente Médio (Bahrein)

918309763551

cn-north-1 - China (Pequim)

961992271922

cn-northwest-1 - China (Ningxia)

Para obter mais informações sobre o uso de políticas de endpoint, consulte Usando políticas de endpoint VPC para controlar o acesso ao Amazon ECR.

Implemente políticas de ciclo de vida para ECR

O Guia de Segurança de Contêineres de Aplicativos do NIST alerta sobre o risco de “imagens obsoletas nos registros”, observando que, com o tempo, imagens antigas e vulneráveis, os pacotes de out-of-date software devem ser removidos para evitar implantação e exposição acidentais. Cada repositório ECR pode ter uma política de ciclo de vida que define regras para quando as imagens expiram. A documentação oficial da AWS descreve como configurar regras de teste, avaliá-las e depois aplicá-las. Há vários exemplos de políticas de ciclo de vida nos documentos oficiais que mostram maneiras diferentes de filtrar as imagens em um repositório:

  • Filtragem por idade ou número de imagens

  • Filtrando por imagens marcadas ou não marcadas

  • Filtragem por tags de imagem, em várias regras ou em uma única regra

??? + aviso Se a imagem de um aplicativo de longa execução for removida do ECR, isso poderá causar erros de extração de imagem quando o aplicativo for reimplantado ou dimensionado horizontalmente. Ao usar políticas de ciclo de vida de imagens, certifique-se de que você tenha boas. CI/CD practices in place to keep deployments and the images that they reference up to date and always create [image] expiry rules that account for how often you do releases/deployments

Criar um conjunto de imagens selecionadas

Em vez de permitir que os desenvolvedores criem suas próprias imagens, considere criar um conjunto de imagens verificadas para as diferentes pilhas de aplicativos em sua organização. Ao fazer isso, os desenvolvedores podem prescindir de aprender a compor Dockerfiles e se concentrar em escrever código. À medida que as alterações são mescladas no Master, um pipeline de CI/CD pode compilar automaticamente o ativo, armazená-lo em um repositório de artefatos e copiar o artefato na imagem apropriada antes de enviá-lo para um registro do Docker, como o ECR. No mínimo, você deve criar um conjunto de imagens básicas a partir das quais os desenvolvedores criem seus próprios Dockerfiles. Idealmente, você deve evitar extrair imagens do Dockerhub porque 1/você nem sempre sabe o que está na imagem e 2/cerca de um quinto das 1000 imagens principais têm vulnerabilidades. Uma lista dessas imagens e suas vulnerabilidades pode ser encontrada aqui.

Adicione a diretiva USER aos seus Dockerfiles para ser executada como um usuário não root

Conforme mencionado na seção de segurança do pod, você deve evitar executar o contêiner como root. Embora você possa configurar isso como parte do PodSpec, é um bom hábito usar a USER diretiva em seus Dockerfiles. A USER diretiva define o UID a ser usado durante a execução RUNENTRYPOINT, ou a CMD instrução que aparece após a diretiva USER.

Lint seus Dockerfiles

O Linting pode ser usado para verificar se seus Dockerfiles estão aderindo a um conjunto de diretrizes predefinidas, por exemplo, a inclusão da USER diretiva ou a exigência de que todas as imagens sejam marcadas. dockerfile_lint é um projeto de código aberto RedHat que verifica as melhores práticas comuns e inclui um mecanismo de regras que você pode usar para criar suas próprias regras para linting de Dockerfiles. Ele pode ser incorporado a um pipeline de CI, pois compilações com Dockerfiles que violam uma regra falharão automaticamente.

Crie imagens do zero

Reduzir a superfície de ataque das imagens do contêiner deve ser o objetivo principal ao criar imagens. A maneira ideal de fazer isso é criando imagens mínimas sem binários que possam ser usadas para explorar vulnerabilidades. Felizmente, o Docker tem um mecanismo a partir do scratchqual criar imagens. Com linguagens como Go, você pode criar um binário vinculado estático e referenciá-lo em seu Dockerfile, como neste exemplo:

############################
# STEP 1 build executable binary
############################
FROM golang:alpine AS builder# Install git.
# Git is required for fetching the dependencies.
RUN apk update && apk add --no-cache gitWORKDIR $GOPATH/src/mypackage/myapp/COPY . . # Fetch dependencies.
# Using go get.
RUN go get -d -v# Build the binary.
RUN go build -o /go/bin/hello

############################
# STEP 2 build a small image
############################
FROM scratch# Copy our static executable.
COPY --from=builder /go/bin/hello /go/bin/hello# Run the hello binary.
ENTRYPOINT ["/go/bin/hello"]

Isso cria uma imagem de contêiner que consiste em seu aplicativo e nada mais, tornando-o extremamente seguro.

Use tags imutáveis com ECR

As tags imutáveis forçam você a atualizar a tag da imagem em cada envio para o repositório de imagens. Isso pode impedir que um invasor substitua uma imagem por uma versão maliciosa sem alterar as tags da imagem. Além disso, oferece uma maneira de identificar uma imagem de forma fácil e exclusiva.

Assine suas imagens SBOMs, execuções de pipeline e relatórios de vulnerabilidade

Quando o Docker foi introduzido pela primeira vez, não havia um modelo criptográfico para verificar imagens de contêineres. Com a v2, o Docker adicionou resumos ao manifesto da imagem. Isso permitiu que a configuração de uma imagem fosse codificada e que o hash fosse usado para gerar um ID para a imagem. Quando a assinatura de imagem está ativada, o mecanismo Docker verifica a assinatura do manifesto, garantindo que o conteúdo tenha sido produzido de uma fonte confiável e que nenhuma violação tenha ocorrido. Depois que cada camada é baixada, o mecanismo verifica o resumo da camada, garantindo que o conteúdo corresponda ao conteúdo especificado no manifesto. A assinatura de imagens permite que você crie efetivamente uma cadeia de suprimentos segura, por meio da verificação das assinaturas digitais associadas à imagem.

Podemos usar o AWS Signer ou o Sigstore Cosign para assinar imagens de contêineres, criar atestados, relatórios de verificação de vulnerabilidade e relatórios de SBOMs execução de pipeline. Esses atestados garantem a confiabilidade e a integridade da imagem, que ela é de fato criada pelo pipeline confiável sem qualquer interferência ou adulteração e que contém somente os componentes de software documentados (no SBOM) que são verificados e confiáveis pelo editor da imagem. Esses atestados podem ser anexados à imagem do contêiner e enviados ao repositório.

Na próxima seção, veremos como usar os artefatos atestados para auditorias e verificação do controlador de admissões.

Verificação da integridade da imagem usando o controlador de admissão Kubernetes

Podemos verificar assinaturas de imagens e artefatos atestados de forma automatizada antes de implantar a imagem no cluster Kubernetes de destino usando o controlador de admissão dinâmico e admitir implantações somente quando os metadados de segurança dos artefatos estiverem em conformidade com as políticas do controlador de admissão.

Por exemplo, podemos escrever uma política que verifica criptograficamente a assinatura de uma imagem, um SBOM atestado, um relatório de execução de pipeline atestado ou um relatório de verificação CVE atestado. Podemos escrever condições na política para verificar os dados no relatório, por exemplo, um escaneamento CVE não deve ter nenhum aspecto críticoCVEs. A implantação é permitida somente para imagens que satisfaçam essas condições e todas as outras implantações serão rejeitadas pelo controlador de admissões.

Exemplos de controlador de admissão incluem:

Atualize os pacotes nas imagens do seu contêiner

Você deve incluir RUN apt-get update && apt-get upgrade em seus Dockerfiles para atualizar os pacotes em suas imagens. Embora a atualização exija que você seja executada como root, isso ocorre durante a fase de criação da imagem. O aplicativo não precisa ser executado como root. Você pode instalar as atualizações e depois mudar para um usuário diferente com a diretiva USER. Se sua imagem base for executada como um usuário não root, alterne para root e vice-versa; não confie apenas nos mantenedores da imagem base para instalar as atualizações de segurança mais recentes.

Execute apt-get clean para excluir os arquivos do instalador do/var/cache/apt/archives/. Você também pode executar rm -rf /var/lib/apt/lists/* depois de instalar os pacotes. Isso remove os arquivos de índice ou as listas de pacotes que estão disponíveis para instalação. Esteja ciente de que esses comandos podem ser diferentes para cada gerenciador de pacotes. Por exemplo:

RUN apt-get update && apt-get install -y \
    curl \
    git \
    libsqlite3-dev \
    && apt-get clean && rm -rf /var/lib/apt/lists/*

Ferramentas e recursos