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 AWS conta. 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
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. SBOMé um alicerce fundamental na segurança de software e no gerenciamento de riscos da cadeia de suprimentos de software. A geração, o armazenamento SBOMS em um repositório central e a verificação SBOMs de vulnerabilidades
-
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 de execução de pipeline atestado junto com um relatório de CVE digitalização atestado SBOM e 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 gerarSBOM:
-
O Amazon Inspector pode ser usado para criar e exportar. SBOMs
-
O Syft da Anchore
também pode ser usado para SBOM geração. Para varreduras de vulnerabilidade mais rápidas, a imagem SBOM gerada para um contêiner pode ser usada como uma entrada para escanear. O relatório SBOM e a digitalização são então atestados e anexados à imagem antes de enviá-la para um OCI repositório central, como a Amazon, ECR para fins de revisão e auditoria.
Saiba mais sobre como proteger sua cadeia de suprimentos de software consultando o guia de melhores práticas da cadeia de suprimentos de CNCF software
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 na Amazon ECR podem ser digitalizadas via push ou sob demanda (uma vez durante um período de 24 horas). ECRatualmente suporta dois tipos de escaneamento: Básico e Avançado. A digitalização básica utiliza a Clair
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 do Kubernetes. API 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
Use atestados para validar a integridade do artefato
Um atestado é uma “declaração” assinada criptograficamente que afirma que algo - um “predicado”, por exemplo, a execução de um pipeline 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.
-
Os atestados podem ser criados usando AWSSigner ou Sigstore cosign.
-
Os controladores de admissão do Kubernetes, como o Kyverno
, podem ser usados para verificar os atestados. -
Consulte este workshop
para saber mais sobre as melhores práticas de gerenciamento da cadeia de suprimentos de software sobre o AWS uso de ferramentas de código aberto com tópicos que incluem a criação e a anexação de atestados a uma imagem de contêiner.
Crie IAM políticas para ECR repositórios
Atualmente, não é incomum que uma organização tenha várias equipes de desenvolvimento operando de forma independente em uma AWS conta compartilhada. Se essas equipes não precisarem compartilhar ativos, talvez você queira criar um conjunto de IAM políticas que restrinjam o acesso aos repositórios com os quais cada equipe pode interagir. Uma boa maneira de implementar isso é usando ECR namespaces. 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 ECR privados
O ECR API tem um endpoint público. Consequentemente, ECR os registros podem ser acessados pela Internet, desde que a solicitação tenha sido autenticada e autorizada pela. 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 ECR API 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 VPCEndpoints de ECR interface da Amazon.
Implemente políticas de endpoint para ECR
A política de endpoint padrão permite o acesso a todos os ECR repositórios 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. AWS A mitigação desse risco envolve a criação de uma política de endpoint que limita o API acesso aos repositórios. ECR Por exemplo, a política a seguir permite que todos AWS os princípios em sua conta realizem todas as ações em seus e somente em seus ECR repositórios:
{ "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 um IAM princípio que não faz parte da sua organização. 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 EKS extrai imagens para kube-proxy, coredns e aws-node, você precisará adicionar o ID da conta do registroECR, 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 AWS contas de onde EKS as imagens 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 VPC endpoint para controlar o acesso à Amazon ECR
Implemente políticas de ciclo de vida para ECR
O NISTApplication Container Security Guide
-
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 removidaECR, 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. 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
Adicione a USER diretiva 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 dopodSpec, é um bom hábito usar a USER
diretiva em seus Dockerfiles. A USER
diretiva define UID a ser usada durante a execuçãoRUN
,ENTRYPOINT
, ou a CMD
instrução que aparece após a USER diretiva.
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
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 scratch
############################ # 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
Assine suas imagensSBOMs, 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 AWSSigner ou o Sigstore Cosign para assinar
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
Por exemplo, podemos escrever uma política que verifica criptograficamente a assinatura de uma imagem, um relatório de execução de pipeline atestado e atestado SBOM ou um relatório de verificação atestado. CVE Podemos escrever condições na política para verificar os dados no relatório, por exemplo, um CVE escaneamento 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 USER diretiva. 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
-
Workshop EKS de imersão em segurança da Amazon — Segurança de imagens
-
docker-slim Crie imagens mínimas
seguras -
dockle
Verifica se seu Dockerfile está alinhado com as melhores práticas para criar imagens seguras -
dockerfile-lint Linter
baseado em regras para Dockerfiles -
hadolint Um linter dockerfile
inteligente -
Gatekeeper e OPA
um controlador de admissão baseado em políticas -
Kyverno Um mecanismo de políticas nativo
do Kubernetes -
in-toto
Permite que o usuário verifique se uma etapa na cadeia de suprimentos foi planejada para ser executada e se a etapa foi executada pelo ator certo -
Notário
Um projeto para assinar imagens de contêineres -
Grafeas
Um metadado de artefato aberto API para auditar e governar sua cadeia de suprimentos de software -
NeuVector por meio
de uma plataforma de segurança de contêineres de código SUSE aberto e de confiança zero, fornece varredura de contêineres, imagens e registros em busca de vulnerabilidades, segredos e conformidade.