Todos os produtos
Search
Central de documentação

Container Service for Kubernetes:Supply chain security

Última atualização: Sep 12, 2026

A segurança da cadeia de suprimentos de software protege o software e seus componentes durante o desenvolvimento, a entrega e o uso contra códigos maliciosos, vulnerabilidades e outros riscos. Este tópico fornece recomendações de segurança para imagens de contêiner, registros e workloads nas etapas de build, deploy e runtime em clusters ACK.

Superfície de ataque por etapa

Etapa

Tipos de ataque

Build

Contaminação de ferramentas de IDE, vulnerabilidades em bibliotecas de terceiros e web shells, contaminação de código-fonte

Deploy

Substituição e adulteração de dados armazenados, sequestro de transmissão de dados, ataques de drive-by download

Runtime

Sequestro de atualizações de software, vulnerabilidades de runtime e web shells, vulnerabilidades zero-day em bibliotecas de terceiros

Uma imagem de contêiner comprometida pode resultar em escape de contêiner, tomada de controle do host e movimentação lateral para dados sensíveis. O controle de admissão do Kubernetes verifica a segurança dos pods no momento do deploy, enquanto o monitoramento contínuo de runtime permite uma resposta rápida a ameaças.

Etapa de build

Crie imagens de contêiner mínimas

Mantenha as imagens de contêiner o menor possível para reduzir a superfície de ataque.

  • Remova binários desnecessários das imagens. Use o Dive para inspecionar camadas de imagens do Docker Hub ou verifique o conteúdo das camadas no console do Container Registry após o push.

  • Elimine todos os binários com bits de permissão SETUID e SETGID, pois atacantes podem usá-los para escalar privilégios.

  • Exclua shells e ferramentas frequentemente exploradas por atacantes, como nc e curl.

Para localizar binários com bits SETUID ou SETGID:

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

Para remover esses bits de permissão no seu Dockerfile:

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

Utilize builds multi-stage

Builds multi-stage empregam múltiplas instruções FROM em um Dockerfile. A imagem final contém apenas os artefatos da aplicação, sem a toolchain de build.

Essa abordagem reduz o tamanho da imagem e a superfície de ataque, além de facilitar a integração em pipelines de CI/CD.

Consulte Build an image for a Java application using a multi-stage Dockerfile.

Execute contêineres como usuário não root

Adicione a instrução USER aos Dockerfiles. Após a definição de USER, as instruções RUN, ENTRYPOINT e CMD são executadas sob esse usuário. Aplique a mesma configuração no PodSpec.

Baixe dependências de fontes confiáveis

Durante a fase de desenvolvimento de software, evite usar pacotes de fontes não confiáveis.

Para gerenciamento interno de dependências, utilize o Apsara DevOps Artifact Repository Packages — um repositório privado com suporte a pacotes Maven, Gradle e npm, oferecendo proxy remoto, migração com um clique, isolamento de tenant, controle de permissões e armazenamento de alta disponibilidade.

Etapa de registro

Restrinja o acesso com políticas do RAM

Utilize políticas do Resource Access Management (RAM) para restringir o acesso a instâncias, namespaces ou repositórios específicos do Container Registry. Por exemplo, cr:ListInstance* corresponde a todas as ações que começam com cr:ListInstance. Defina o recurso como acs:cr:*:*:repository/$instanceid/$namespace/* — por exemplo, acs:cr:cn-hangzhou:1234567:repository/cri-123456/ns/* concede à instância cri-123456 em cn-hangzhou, pertencente à conta 1234567, acesso de consulta a todos os repositórios no namespace ns. A política a seguir concede acesso somente leitura a um namespace em uma instância específica:

{
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "cr:ListRepository",
                "cr:GetImageLayer",
                "cr:GetRepoTag"
            ],
            "Resource": "*"
        },
        {
            "Action": [
                "cr:List*"
            ],
            "Effect": "Allow",
            "Resource": [
                "acs:cr:cn-hangzhou:1234567:repository/cri-123456/ns/*"
            ]
        }
    ],
    "Version": "1"
}

Consulte RAM authentication rules e Grant permissions to a RAM role for custom OSS buckets.

Use o Container Registry Enterprise Edition em produção

O Container Registry Enterprise Edition oferece criptografia de artefatos, relatórios multidimensionais de vulnerabilidades, auditoria granular de ações e controle de acesso para imagens de contêiner e Helm charts.

Para ambientes de produção:

  • Defina os repositórios como private.

  • Acesse o Container Registry por meio de uma Virtual Private Cloud (VPC) utilizando endpoints internos. Desative o acesso pela internet pública.

  • Configure listas de controle de acesso (ACLs) de rede para restringir o tráfego de entrada.

Consulte Create a Container Registry Enterprise Edition instance.

Verifique vulnerabilidades nas imagens

O Container Registry examina automaticamente novas imagens enviadas e reexamina todas as imagens existentes a cada 24 horas.

  • Caso uma imagem contenha vulnerabilidades classificadas como HIGH ou CRITICAL, exclua-a ou reconstrua-a imediatamente.

  • Se imagens vulneráveis já estiverem em deploy, substitua os contêineres afetados o mais rápido possível.

Para impor a verificação antes do deploy, configure um webhook de validação do Kubernetes que rejeite solicitações em desacordo com as políticas de admissão. Chame CreateRepoTagScanTask para verificar se as imagens sendo baixadas contêm vulnerabilidades críticas. Se encontradas, o Container Registry bloqueia o deploy do pod e gera um evento listando os problemas.

Consulte CreateRepoTagScanTask.

Assine imagens e valide assinaturas

A assinatura de imagens previne ataques man-in-the-middle (MITM) e atualizações ou deploys não autorizados, garantindo a integridade da imagem desde a distribuição até o deploy.

O Container Registry Enterprise Edition suporta assinatura automática em namespaces específicos. Após um push, o Container Registry assina a imagem com base nas regras de assinatura correspondentes. Consulte Sign container images.

Etapa de deploy

Imponha a verificação de assinatura com kritis-validation-hook

Instale o kritis-validation-hook em clusters ACK para validar assinaturas de imagens de contêiner durante o deploy. Baseado no projeto open-source Kritis, ele se integra ao Container Registry e ao Key Management Service (KMS).

Somente imagens aprovadas na verificação podem ser executadas no cluster. Para excluir imagens de contêiner sidecar injetadas por componentes de terceiros, adicione-as à lista de permissões de verificação.

Consulte:

Adote a cadeia de entrega nativa da cloud

O Container Registry oferece uma cadeia de entrega nativa da cloud que abrange build de imagens, verificação, sincronização global e distribuição — com observabilidade, rastreabilidade e segurança.

Após o push de uma imagem, o Container Registry a examina e aplica as políticas de segurança configuradas. Imagens que ultrapassam o limiar de severidade são bloqueadas para distribuição e deploy.

Integre a API de verificação de imagens aos seus sistemas para agendar verificações sob demanda. Consulte Create a delivery chain.

Etapa de runtime

Monitore runtimes com o Security Center

O Security Center detecta e bloqueia ameaças em runtimes nativos da cloud, protegendo cada pod.

Ele coleta automaticamente inteligência de ameaças, rastreia origens de ataques e responde em tempo real. As capacidades incluem:

  • Detecção de execução de código ou comandos maliciosos, injeção de SQL e violações de dados

  • Correlação de dados de log entre diferentes fontes para identificar padrões de risco em contexto

  • Auditoria de ações e identificação de riscos a partir de logs do Kubernetes e logs de operações

  • Mitigação de escapes de contêiner, vazamentos de AccessKey e acessos não autorizados no ACK e em outras plataformas de orquestração

Consulte What is Security Center?

Referências