Todos os produtos
Search
Central de documentação

Container Compute Service:Use configuration inspection to check cluster workloads

Última atualização: Oct 14, 2026

Container Compute Service (ACS) oferece inspeção de configurações de workload para identificar riscos de segurança no cluster. Após a execução de uma tarefa de inspeção, o ACS gera um relatório de inspeção. Com base nesse relatório, revise e corrija os itens de risco do cluster e monitore a integridade dele em tempo real.

Pré-requisitos

  • Você tem criado um cluster ACS.

  • Se você estiver usando um usuário RAM, certifique-se de ter concluído a autorização RAM e a autorização RBAC conforme descrito abaixo.

    • Autorização RAM

      Conclua a autorização RAM para a página de inspeção de configuração do ACS para garantir que o usuário RAM atual tenha permissões para operar a página de inspeção de configuração do cluster atual. Caso contrário, não será possível usar os recursos da página devido à falta de permissões. Para obter mais informações, consulte Grant RAM permissions.

      Expanda para visualizar o código de autorização de inspeção de configuração

      {
        "Statement": [
          {
            "Action": [
              "cs:DescribePolarisConfig",
              "cs:DescribePolarisJob",
              "cs:DescribePolarisCronJob",
              "cs:UpdatePolarisJob",
              "cs:UpdatePolarisCronJob"
            ],
            "Effect": "Allow",
            "Resource": [
              "acs:cs:*:*:cluster/<yourclusterID>"
            ]
          }
        ],
        "Version": "1"
      }

      Para usar também o recurso de relatório de inspeção, conclua a autorização RAM para o logproject especificado do Simple Log Service (SLS) (o logproject usado pelo complemento logtail-ds do cluster atual). Isso permite que o usuário RAM atual tenha permissões para ler dados desse logproject do SLS. Sem essa autorização, não será possível visualizar os relatórios de inspeção devido à falta de permissões. Para obter mais informações, consulte RAM custom policy examples.

      Expanda para visualizar o código de autorização de leitura de logs do SLS

      {
          "Version": "1",
          "Statement": [
              {
                  "Action": [
                      "log:Get*",
                      "log:List*"
                  ],
                  "Resource": "acs:log:*:*:project/<指定的Project名称>/*",
                  "Effect": "Allow"
              }
          ]
      }
    • Autorização RBAC

      Conclua a autorização RBAC para os recursos envolvidos na página de inspeção de configuração do ACS e conceda ao usuário RAM permissões de administrador em um cluster específico. Isso garante que o usuário RAM tenha permissões para operar os recursos Kubernetes relacionados à página de inspeção de configuração. Para obter mais informações, consulte Configure RBAC permissions for RAM users or roles.

Ative o recurso de inspeção de configuração de workload para o seu cluster

  1. Faça login no console do ACS. No painel de navegação à esquerda, clique em Clusters.

  2. Na página Clusters, clique no nome do cluster desejado. No painel de navegação à esquerda, escolha Security > Inspections.

  3. Opcional: Instale e atualize o complemento de inspeção.

    Se esta for sua primeira utilização e o complemento de inspeção não estiver instalado, siga as instruções na tela para instalar o complemento security-inspector. Se o complemento de inspeção não estiver na versão mais recente, siga as instruções na tela para atualizá-lo. Após a instalação, você também pode acessar a página Cluster Information e, na aba Overview, clique em Security Inspection para ir até a página Inspections.

    Para obter mais informações sobre o complemento security-inspector e seu histórico de alterações, consulte security-inspector.

  4. No canto superior direito da página Inspections, clique em Inspect. Após a conclusão da inspeção, na coluna Ações da aba Inspections, clique em Details para visualizar os detalhes da inspeção.

    Importante

    Para melhorar a estabilidade e a disponibilidade do sistema, garantindo a continuidade dos negócios e a experiência do usuário, execute as inspeções fora dos horários de pico.

  5. Opcional: No canto superior direito da página Inspections, clique em Configure Periodic Inspection para ativar ou desativar a execução automática agendada de inspeções de configuração e definir os itens de verificação executados durante a inspeção.

Detalhes da inspeção

A página Inspections exibe os resultados detalhados da inspeção de diferentes workloads em tabelas e oferece os seguintes recursos:

  • Filtra os resultados por critérios como Passed or Failed, Namespace e Workload Type, exibindo a Number of Passed Items e a Number of Failed Items para cada workload.

  • Apresenta os detalhes de cada item de verificação nos resultados da inspeção, incluindo o status de verificação no nível do Pod e do contêiner (aprovado ou reprovado), a descrição detalhada do item e a recomendação de correção. Se um item reprovado não exigir ação, adicione-o à lista de permissões.

  • Permite visualizar o arquivo YAML da workload.

Relatório de inspeção

O relatório de inspeção exibe os resultados da varredura mais recente e inclui os seguintes tipos de informações:

  • Uma visão geral da varredura, incluindo o número total de entradas verificadas, a quantidade e a porcentagem de cada item de recurso verificado e a pontuação geral de integridade.

  • Estatísticas dos resultados da varredura por categoria principal, abrangendo categorias como verificação de integridade, imagem, rede, recurso e segurança.

  • Os resultados detalhados da varredura de cada configuração de workload, incluindo tipo de recurso, nome do recurso, namespace, tipo de verificação, item de verificação e resultado da verificação.

Item de verificação

O recurso de inspeção de configuração verifica e exibe os resultados dos seguintes itens.

Item de verificação

O que é verificado e o risco de segurança

Recomendação de correção

hostNetworkSet

Verifica se o Pod Spec da workload especifica hostNetwork: true, indicando se o Pod está configurado para compartilhar e usar o namespace de rede do host. Se esse campo estiver configurado, os contêineres no Pod poderão atacar a rede do host e interceptar dados nessa rede.

Modifique o Pod Spec e remova o campo hostNetwork.

Exemplo:

      labels:
        app: nginx
      spec:
-       hostNetwork: true
        containers:
        - name: nginx
          image: nginx:1.14.2

hostIPCSet

Verifica se o Pod Spec da workload especifica hostIPC: true, indicando se o Pod está configurado para compartilhar e usar o namespace IPC do host. Se esse campo estiver configurado, os contêineres no Pod poderão atacar processos no host e interceptar dados desses processos.

Modifique o Pod Spec e remova o campo hostIPC.

Exemplo:

      labels:
        app: nginx
      spec:
-       hostIPC: true
        containers:
        - name: nginx
          image: nginx:1.14.2

hostPIDSet

Verifica se o Pod Spec da workload especifica hostPID: true, indicando se o Pod está configurado para compartilhar e usar o namespace PID do host. Se esse campo estiver configurado, os contêineres no Pod poderão atacar processos no host e coletar dados desses processos.

Modifique o Pod Spec e remova o campo hostPID.

Exemplo:

      labels:
        app: nginx
      spec:
-       hostPID: true
        containers:
        - name: nginx
          image: nginx:1.14.2

hostPortSet

Verifica se o Pod Spec da workload especifica hostPort, indicando se a porta em que um contêiner escuta está mapeada para uma porta específica no host. Se esse campo estiver configurado, o contêiner poderá ocupar portas disponíveis no host, permitindo que solicitantes inesperados enviem requisições para a porta do contêiner.

Modifique o Pod Spec e remova o campo hostPort.

Exemplo:

    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
-         hostPort: 80

runAsRootAllowed

Verifica se o Pod Spec da workload não especifica runAsNonRoot: true, indicando se os contêineres não estão configurados para executar como um usuário não root. Se esse campo não estiver configurado, processos maliciosos em um contêiner poderão comprometer aplicações do usuário, o host ou até mesmo todo o cluster.

Modifique o Pod Spec e adicione runAsNonRoot: true.

Exemplo:

    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
+       securityContext:
+         runAsNonRoot: true

runAsPrivileged

Verifica se o Pod Spec da workload especifica privileged: true, indicando se os contêineres têm permissão para executar em modo privilegiado. Se esse campo estiver configurado, processos maliciosos em um contêiner poderão comprometer aplicações do usuário, o host ou até mesmo o cluster.

Modifique o Pod Spec e remova o campo privileged.

Exemplo:

    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
        securityContext:
-         privileged: true

privilegeEscalationAllowed

Verifica se o Pod Spec da workload não especifica allowPrivilegeEscalation: false, indicando se os processos filhos em um contêiner não são proibidos de obter privilégios superiores aos do processo pai. Se esse campo não estiver configurado, processos maliciosos em um contêiner poderão realizar escalonamento de privilégios.

Modifique o Pod Spec e adicione o campo allowPrivilegeEscalation:false.

Exemplo:

        ports:
        - containerPort: 80
        securityContext:
+         allowPrivilegeEscalation: false
          readOnlyRootFilesystem: true
          runAsNonRoot: true
      volumeMounts:

capabilitiesAdded

Verifica o campo capabilities no Pod Spec da workload, indicando se os processos em um contêiner têm permissão para possuir capacidades privilegiadas do Linux, como SYS_ADMIN, NET_ADMIN e ALL. Se esse campo estiver configurado, processos maliciosos em um contêiner poderão usar esses privilégios para comprometer aplicações do usuário ou danificar complementos e o cluster.

Modifique o Pod Spec para adicionar apenas as capacidades do Linux necessárias conforme suas necessidades reais e remova as capacidades desnecessárias.

Se nenhuma capacidade adicional do Linux for necessária, remova todas as capacidades desnecessárias. Exemplo:

    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
        securityContext:
          capabilities:
-           add:
-           - SYS_ADMIN
-           - NET_ADMIN
-           - KILL
+           drop:
+           - ALL

Adicione apenas as capacidades do Linux necessárias e remova todas as desnecessárias. Exemplo:

    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
        securityContext:
          capabilities:
            add:
-           - SYS_ADMIN
-           - NET_ADMIN
-           - KILL
+           - CHOWN
+           drop:
+           - ALL

notReadOnlyRootFileSystem

Verifica se o Pod Spec da workload não especifica readOnlyRootFilesystem: true, indicando se o sistema de arquivos em um contêiner não está configurado como somente leitura. Se esse campo não estiver configurado, processos maliciosos em um contêiner poderão modificar arquivos do sistema.

Modifique o Pod Spec e adicione readOnlyRootFilesystem: true.

Exemplo:

    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
        securityContext:
+         readOnlyRootFilesystem: true

Se precisar modificar arquivos em um diretório, use o campo volumeMounts.

Exemplo:

    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
        securityContext:
+         readOnlyRootFilesystem: true
          runAsNonRoot: true
+       volumeMounts:
+       - mountPath: /path/to/write
+         name: writeable
+   volumes:
+   - emptyDir: {}
+     name: writeable

cpuRequestsMissing

Verifica se o Pod Spec da workload não especifica o campo resources.requests.cpu, indicando se os recursos mínimos de CPU necessários para executar um contêiner não estão configurados. Se esse campo não estiver configurado, o Pod poderá ser agendado em um nó com recursos insuficientes, causando lentidão nos processos do contêiner.

Modifique o Pod Spec e adicione o campo resources.requests.cpu.

Exemplo:

    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
+       resources:
+         requests:
+           cpu: 100m
        ports:

cpuLimitsMissing

Verifica se o Pod Spec da workload não especifica o campo resources.limits.cpu, indicando se os recursos máximos de CPU necessários para executar um contêiner não estão configurados. Se esse campo não estiver configurado, processos anormais em um contêiner poderão consumir uma grande quantidade de recursos do nó, podendo esgotar os recursos de todo o nó ou cluster.

Modifique o Pod Spec e adicione o campo resources.limits.cpu.

Exemplo:

    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        resources:
          requests:
            cpu: 100m
+         limits:
+           cpu: 100m
        ports:

memoryRequestsMissing

Verifica se o Pod Spec da workload não especifica o campo resources.requests.memory, indicando se os recursos mínimos de memória necessários para executar um contêiner não estão configurados. Se esse campo não estiver configurado, o Pod poderá ser agendado em um nó com recursos insuficientes, fazendo com que os processos no contêiner fiquem sem memória (OOM).

Modifique o Pod Spec e adicione o campo resources.requests.memory.

Exemplo:

    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        resources:
          requests:
            cpu: 100m
+           memory: 128Mi
          limits:

memoryLimitsMissing

Verifica se o Pod Spec da workload não especifica o campo resources.limits.memory, indicando se os recursos máximos de memória necessários para executar um contêiner não estão configurados. Se esse campo não estiver configurado, processos anormais em um contêiner poderão consumir uma grande quantidade de recursos do nó, podendo esgotar os recursos de todo o nó ou cluster.

Modifique o Pod Spec e adicione o campo resources.limits.memory.

Exemplo:

    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 100m
+           memory: 128Mi
        ports:

readinessProbeMissing

Verifica se o Pod Spec da workload não especifica o campo readinessProbe, indicando se não há configuração de uma sonda para detectar se a aplicação no contêiner pode lidar adequadamente com requisições. Se esse campo não estiver configurado, requisições poderão continuar sendo enviadas para a aplicação no contêiner mesmo quando ela estiver anormal e incapaz de processá-las, causando exceções de negócio.

Modifique o Pod Spec e adicione o campo readinessProbe.

Exemplo:

    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
+       readinessProbe:
+         httpGet:
+           path: /health
+           port: 8080
+         initialDelaySeconds: 5
+         periodSeconds: 20
        resources:

livenessProbeMissing

Verifica se o Pod Spec da workload não especifica livenessProbe, indicando se não há configuração de uma sonda para detectar se a aplicação no contêiner está anormal e se o contêiner precisa ser reiniciado. Se esse campo não estiver configurado, o contêiner poderá não ser reiniciado a tempo quando a aplicação apresentar anomalias recuperáveis apenas após reinicialização, causando exceções de negócio.

Modifique o Pod Spec e adicione o campo livenessProbe.

Exemplo:

    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
+       livenessProbe:
+         httpGet:
+           path: /health
+           port: 8080
+         initialDelaySeconds: 5
+         periodSeconds: 20
        readinessProbe:

tagNotSpecified

Verifica no Pod Spec da workload se o valor do campo image não contém uma tag de imagem ou usa "latest" como tag, indicando se não foi configurada uma imagem de contêiner com uma tag específica para executar o contêiner. Se esse campo não estiver configurado corretamente, uma versão inesperada da imagem poderá ser executada, causando exceções de negócio.

Modifique o Pod Spec e altere o campo image para usar uma tag de imagem específica, evitando o uso de "latest".

Exemplo:

    spec:
      containers:
      - name: nginx
-       image: nginx:latest
+       image: nginx:1.14.2
        livenessProbe:

anonymousUserRBACBinding

Verifica as vinculações de controle de acesso baseado em função (RBAC) no cluster para identificar configurações que concedem permissões de acesso a usuários anônimos. Se uma configuração permitir que usuários anônimos acessem recursos do cluster, usuários mal-intencionados poderão roubar informações sensíveis e atacar ou comprometer o cluster.

Modifique as vinculações RBAC detectadas pela varredura e remova as configurações de permissão que permitem acesso anônimo aos recursos do cluster, conforme suas necessidades reais.

Exemplo:

  - apiGroup: rbac.authorization.k8s.io
    kind: Group
    name: 'foo-group'
- - apiGroup: rbac.authorization.k8s.io
-   kind: User
-   name: 'system:anonymous'
- - apiGroup: rbac.authorization.k8s.io
-   kind: Group
-   name: 'system:unauthenticated'

Eventos

Tipo de evento

Nome do evento

Mensagem de exemplo do evento

Descrição do evento

Ação

Normal

SecurityInspectorConfigAuditStart

Start to running config audit

A tarefa de inspeção foi iniciada.

Nenhuma ação é necessária.

Normal

SecurityInspectorConfigAuditFinished

Finished running once config audit

A tarefa de inspeção foi concluída.

Nenhuma ação é necessária.

Warning

SecurityInspectorConfigAuditHighRiskFound

2 high risks have been found after running config audit

Após a conclusão da inspeção, foram encontrados itens de verificação de alto risco não corrigidos em algumas workloads.

  1. Na página Inspections do cluster, visualize os resultados detalhados da inspeção.

  2. Use as opções de filtro Failed, All Namespaces e Show All Workloads para filtrar e visualizar as workloads com riscos. Em seguida, clique em Details para ver o resultado da verificação e a recomendação de correção de cada item na workload.

    • Para um item de verificação que você confirmou não precisar de correção, clique em Add to Whitelist para adicioná-lo à lista de permissões.

    • Para um item de verificação que você confirmou precisar de correção, realize a correção seguindo a recomendação fornecida.