Ative, consulte e configure alertas para logs de auditoria do servidor de API a fim de atender aos requisitos de conformidade e segurança.
A auditoria de cluster registra as solicitações e respostas do servidor de API, permitindo rastrear o histórico de operações e investigar anomalias.
Aplica-se a clusters ACK gerenciados, ACK dedicados e ACK Serverless.
Para clusters registrados, consulte Usar auditoria de cluster .
Faturamento
Os dados de log de auditoria utilizam faturamento por recurso. Consulte Visualizar suas faturas e Pagamento por recurso.
A ativação da auditoria de cluster gera custos no Simple Log Service (SLS). Monitore o volume de logs e defina um período de retenção compatível com seus requisitos de conformidade. Padrão: 30 dias para clusters ACK gerenciados e 365 dias para clusters ACK dedicados.
Pré-requisitos
Verifique se as seguintes cotas do SLS em sua conta Alibaba Cloud são suficientes:
Cota de projetos SLS
Cota de Logstores por projeto SLS
Cota de painéis por projeto SLS
Consulte Ajustar cotas de recursos para obter detalhes sobre cotas e solicitar aumentos.
Ativar auditoria de cluster
Por padrão, a opção Enable Log Service fica selecionada durante a criação do cluster. Caso você a tenha desativado, siga estas etapas para reativá-la.
Faça login no console ACK. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, clique no nome do cluster. No painel à esquerda, escolha Security > Cluster Auditing.
Selecione um projeto SLS e ative a auditoria de cluster.
O ACK cria automaticamente um Logstore chamado audit-${clustereid} no projeto.
Não modifique os índices padrão. Alterações impedem a geração correta dos relatórios de auditoria.
Visualizar relatórios de log de auditoria
O ACK oferece quatro relatórios integrados de log de auditoria. Filtre por namespace ou usuário RAM na página Cluster Auditing.
Não modifique os relatórios integrados de log de auditoria. Em vez disso, crie relatórios personalizados no console SLS.
Clique no ícone
em qualquer gráfico para visualizá-lo em tela cheia ou visualizar sua instrução de consulta.
Visão geral
Exibe todos os eventos do cluster e detalhes de eventos de alta prioridade, incluindo operações de usuários RAM, acesso à Internet, execuções de comandos, exclusões de recursos, acessos a Secrets e vulnerabilidades CVE.
Visão geral das operações
Fornece estatísticas sobre operações de criação, atualização, exclusão e leitura nas seguintes categorias:
Recursos de computação: Deployment, StatefulSet, CronJob, DaemonSet, Job e Pod
Recursos de rede: Service e Ingress
Recursos de armazenamento: ConfigMap, Secret e PersistentVolumeClaim (PVC)
Recursos de controle de acesso: Role, ClusterRole, RoleBinding e ClusterRoleBinding

Detalhes da operação
Mostra operações para um tipo específico de recurso. Selecione um tipo de recurso para consultar. O relatório exibe a contagem total, distribuição por namespace, taxa de sucesso e tendências ao longo do tempo.

Para consultar recursos CRD ou recursos não listados, insira o nome do recurso no plural. Por exemplo, para consultarAliyunLogConfig, insiraAliyunLogConfigs.
Vulnerabilidades CVE
Exibe vulnerabilidades CVE do Kubernetes. Filtre pelo ID do usuário RAM. Consulte [[Segurança CVE] Correções de vulnerabilidades CVE](https://www.alibabacloud.com/help/en/document_detail/102548.html) para obter informações sobre correção.
Consultar dados detalhados de log
Para consultas personalizadas e análises mais profundas, acesse os dados brutos do log de auditoria no console SLS.
Retenção padrão: 30 dias para clusters ACK gerenciados e 365 dias para clusters ACK dedicados. Consulte Gerenciar um Logstore para alterar o período de retenção.
Faça login no console ACK. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, clique no nome do cluster. No painel à esquerda, clique em Cluster Information.
Na aba Cluster Resources, clique no ID do projeto ao lado de Log Service Project. Na lista de Logstores, clique no Logstore chamado audit-${clustereid}.
Insira uma instrução de consulta, configure o intervalo de tempo da consulta (por exemplo, os últimos 15 minutos) e clique em Search & Analysis.
Padrões comuns de consulta:
Por usuário RAM: Insira o ID do usuário RAM.
Por recurso: Insira o nome do recurso (Deployment, Service, ConfigMap ou similar).
-
Excluir componentes do sistema: Filtre o ruído gerado por componentes do sistema:
NOT user.username: node NOT user.username: serviceaccount NOT user.username: apiserver NOT user.username: kube-scheduler NOT user.username: kube-controller-manager
Consulte Métodos de consulta para obter detalhes sobre a sintaxe.
Configurar alertas
Configure regras de alerta do SLS para receber notificações em tempo real quando ocorrerem operações específicas. Os métodos suportados incluem chatbots do DingTalk, webhooks personalizados e o Centro de Mensagens da Alibaba Cloud.
Consulte Configurar uma regra de alerta no SLS.
Exemplo de alerta 1: Comandos executados em containers
Gera alertas quando usuários executam comandos em containers. Cada alerta inclui o container, comando, usuário, ID do evento, horário e endereço IP de origem.
Instrução de consulta de exemplo:
verb : create and objectRef.subresource:exec and stage: ResponseStarted | SELECT auditID as "Event ID", date_format(from_unixtime(__time__), '%Y-%m-%d %T' ) as "Time", regexp_extract("requestURI", '([^\?]*)/exec\?.*', 1)as "Resource", regexp_extract("requestURI", '\?(.*)', 1)as "Command" ,"responseStatus.code" as "Status code",
CASE
WHEN "user.username" != 'kubernetes-admin' then "user.username"
WHEN "user.username" = 'kubernetes-admin' and regexp_like("annotations.authorization.k8s.io/reason", 'RoleBinding') then regexp_extract("annotations.authorization.k8s.io/reason", ' to User "(\w+)"', 1)
ELSE 'kubernetes-admin' END
as "User account",
CASE WHEN json_array_length(sourceIPs) = 1 then json_format(json_array_get(sourceIPs, 0)) ELSE sourceIPs END
as "Source IP address" order by "Time" desc limit 10000
Expressão de condição: Event =~ ".*"
Exemplo de alerta 2: Falha no acesso à Internet pelo servidor de API
Monitora solicitações de saída para a Internet originadas no seu cluster. Dispara quando a contagem de solicitações atinge 10 e a taxa de falha excede 50%.
Instrução de consulta de exemplo:
* | select ip as "Source IP address", total as "Number of times of Internet access", round(rate * 100, 2) as "Failure rate in percentage", failCount as "Number of times of illegal access", CASE when security_check_ip(ip) = 1 then 'yes' else 'no' end as "Whether the IP address is risky", ip_to_country(ip) as "Country", ip_to_province(ip) as "Province", ip_to_city(ip) as "City", ip_to_provider(ip) as "ISP" from (select CASE WHEN json_array_length(sourceIPs) = 1 then json_format(json_array_get(sourceIPs, 0)) ELSE sourceIPs END
as ip, count(1) as total,
sum(CASE WHEN "responseStatus.code" < 400 then 0
ELSE 1 END) * 1.0 / count(1) as rate,
count_if("responseStatus.code" = 403) as failCount
from log group by ip limit 10000) where ip_to_domain(ip) != 'intranet' and ip not LIKE '%,%' and not try(is_subnet_of('7.0.0.0/8', ip)) ORDER by "Number of times of Internet access" desc limit 10000
Expressão de condição: Source IP address =~ ".*"
Gerenciar configurações de auditoria de cluster
Alterar o projeto SLS
Para migrar logs de auditoria para outro projeto SLS:
Faça login no console ACK. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, clique no nome do cluster. No painel à esquerda, escolha Security > Cluster Auditing.
Clique em Change Log Service Project e siga as instruções.
Desativar auditoria de cluster
Faça login no console ACK. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, clique no nome do cluster. No painel à esquerda, escolha Security > Cluster Auditing.
Clique em Disable Cluster Auditing.
Usar um serviço de log de terceiros (apenas clusters ACK dedicados)
O SLS é o armazenamento recomendado para logs de auditoria. Para usar um serviço de log de terceiros, ignore o SLS durante a criação do cluster e integre o serviço externo. Os logs de auditoria brutos estão disponíveis nos nós mestres em /var/log/kubernetes/kubernetes.audit no formato JSON.
Política de auditoria e configuração de backend (clusters ACK dedicados)
Em clusters ACK dedicados, a opção Enable Log Service vem selecionada por padrão. Os eventos de auditoria são coletados conforme a política de auditoria e gravados no sistema de arquivos de log do backend.
Política de auditoria
A política de auditoria define quais eventos coletar e o nível de detalhe. Existem quatro níveis de auditoria:
|
Nível de auditoria |
O que é coletado |
|
None |
Nada. Eventos correspondentes são ignorados. |
|
Metadata |
Apenas metadados da solicitação, como informações do usuário e carimbos de data/hora. Sem corpo de solicitação ou resposta. |
|
Request |
Metadados e corpo da solicitação. Sem corpo de resposta. Solicitações sem recurso são excluídas. |
|
RequestResponse |
Metadados da solicitação, corpo da solicitação e corpo da resposta. Solicitações sem recurso são excluídas. |
A política de auditoria é carregada de /etc/kubernetes/audit-policy.yml nos nós mestres (por meio da flag --audit-policy-file). Política padrão do ACK:
apiVersion: audit.k8s.io/v1 # Required. Set to audit.k8s.io/v1 if the Kubernetes version of the cluster is 1.24 or later and set to audit.k8s.io/v1beta1 if the Kubernetes version of the cluster is earlier than 1.24.
kind: Policy
# No need to generate audit events at the RequestReceived stage.
omitStages:
- "RequestReceived"
rules:
# The following types of requests are frequent and the risk of these requests is low. We recommend that you set the rule to None to skip these requests.
- level: None
users: ["system:kube-proxy"]
verbs: ["watch"]
resources:
- group: "" # core
resources: ["endpoints", "services"]
- level: None
users: ["system:unsecured"]
namespaces: ["kube-system"]
verbs: ["get"]
resources:
- group: "" # core
resources: ["configmaps"]
- level: None
users: ["kubelet"] # legacy kubelet identity
verbs: ["get"]
resources:
- group: "" # core
resources: ["nodes"]
- level: None
userGroups: ["system:nodes"]
verbs: ["get"]
resources:
- group: "" # core
resources: ["nodes"]
- level: None
users:
- system:kube-controller-manager
- system:kube-scheduler
- system:serviceaccount:kube-system:endpoint-controller
verbs: ["get", "update"]
namespaces: ["kube-system"]
resources:
- group: "" # core
resources: ["endpoints"]
- level: None
users: ["system:apiserver"]
verbs: ["get"]
resources:
- group: "" # core
resources: ["namespaces"]
# Set the rule to None for read-only URLs, such as /healthz*, /version*, and /swagger*.
- level: None
nonResourceURLs:
- /healthz*
- /version
- /swagger*
# Set the rule to None for events.
- level: None
resources:
- group: "" # core
resources: ["events"]
# Set the rule to Metadata for Secrets, ConfigMaps, and TokenReview API requests that may contain sensitive information or binary files.
- level: Metadata
resources:
- group: "" # core
resources: ["secrets", "configmaps"]
- group: authentication.k8s.io
resources: ["tokenreviews"]
# Responses may contain large amounts of data. Set the rule to Request so that the response body is not collected.
- level: Request
verbs: ["get", "list", "watch"]
resources:
- group: "" # core
- group: "admissionregistration.k8s.io"
- group: "apps"
- group: "authentication.k8s.io"
- group: "authorization.k8s.io"
- group: "autoscaling"
- group: "batch"
- group: "certificates.k8s.io"
- group: "extensions"
- group: "networking.k8s.io"
- group: "policy"
- group: "rbac.authorization.k8s.io"
- group: "settings.k8s.io"
- group: "storage.k8s.io"
# The rule is set to RequestResponse by default for known Kubernetes API requests to collect the request and response bodies.
- level: RequestResponse
resources:
- group: "" # core
- group: "admissionregistration.k8s.io"
- group: "apps"
- group: "authentication.k8s.io"
- group: "authorization.k8s.io"
- group: "autoscaling"
- group: "batch"
- group: "certificates.k8s.io"
- group: "extensions"
- group: "networking.k8s.io"
- group: "policy"
- group: "rbac.authorization.k8s.io"
- group: "settings.k8s.io"
- group: "storage.k8s.io"
# The rule is set to Metadata by default for other requests.
- level: Metadata
Comportamentos principais:
Os logs são gerados após o envio dos cabeçalhos de resposta, não quando as solicitações são recebidas.
Solicitações watch do kube-proxy, solicitações GET do kubelet e de
system:nodespara nós, operações de endpoint no kube-system e solicitações GET do servidor de API para namespaces são excluídas.Operações de leitura (
get,list,watch) para as APIsauthentication,rbac,certificates,autoscalingestoragesão registradas no nívelRequest. Operações de escrita nessas APIs são registradas no nívelRequestResponse.Secrets e ConfigMaps são registrados apenas no nível
Metadata, portanto, seu conteúdo nunca é gravado nos logs de auditoria.
Backend de auditoria
Os eventos de auditoria são gravados como arquivos JSON no sistema de arquivos local dos nós mestres. A configuração do servidor de API em /etc/kubernetes/manifests/kube-apiserver.yaml controla o comportamento do backend com as seguintes flags:
|
Flag |
Descrição |
Padrão |
|
|
Máximo de arquivos de log rotacionados a serem retidos |
|
|
|
Tamanho máximo por arquivo de log antes da rotação |
|
|
|
Caminho de saída para arquivos de log de auditoria |
|
|
|
Período de retenção para arquivos de log rotacionados |
|
|
|
Caminho para o arquivo de política de auditoria |
|
Próximas etapas
Consulte Ativar auditoria de container para auditar comandos
kubectl execem containers.Consulte Melhores práticas de segurança para segurança corporativa.