Ative, consulte e configure alertas para logs de auditoria do API server a fim de atender aos requisitos de conformidade e segurança.
A auditoria de cluster registra requisições e respostas do API server, o que permite 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 Use cluster auditing .
Faturamento
Os dados de log de auditoria usam faturamento por recurso. Consulte Visualize your bills e Pay-by-feature.
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 adequado às suas exigências de conformidade. Padrão: 30 dias para clusters ACK gerenciados e 365 dias para clusters ACK dedicados.
Pré-requisitos
Verifique se as cotas do SLS na 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 Adjust resource quotas para obter detalhes sobre cotas e solicitar aumentos.
Ativar auditoria de cluster
Por padrão, a opção Enable Log Service vem selecionada durante a criação do cluster. Se você a desativou, 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 logs de auditoria
O ACK oferece quatro relatórios integrados de logs de auditoria. Filtre por namespace ou usuário RAM na página Cluster Auditing.
Não modifique os relatórios integrados de logs de auditoria. Crie relatórios personalizados no console SLS.
Clique no ícone
em qualquer gráfico para visualizá-lo em tela cheia ou pré-visualizar a 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ção de comandos, exclusão de recursos, acesso 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 nos seguintes recursos:
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 de um tipo específico de recurso. Selecione um tipo de recurso para consultar. O relatório exibe a contagem total, a distribuição por namespace, a taxa de sucesso e as tendências ao longo do tempo.
Para consultar recursos CRD ou 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 [[CVE Security] CVE vulnerability fixes](t96487.xdita#) para correção.
Consultar dados detalhados de log
Para consultas personalizadas e análises mais profundas, acesse os dados brutos dos logs de auditoria no console SLS.
Retenção padrão: 30 dias para clusters ACK gerenciados e 365 dias para clusters ACK dedicados. Consulte Gerencie a 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 (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 Query methods para obter detalhes sobre a sintaxe.
Configurar alertas
Defina regras de alerta do SLS para receber notificações em tempo real quando ocorrerem operações específicas. Os métodos compatíveis incluem chatbots do DingTalk, webhooks personalizados e o Centro de Mensagens da Alibaba Cloud.
Consulte Configure an alert rule in SLS.
Exemplo de alerta 1: Comandos executados em containers
Gera alertas quando usuários executam comandos em containers. Cada alerta inclui o container, o comando, o usuário, o ID do evento, o horário e o 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 API server
Monitora requisições de saída para a Internet originadas no cluster. Dispara quando a contagem de requisições atinge 10 e a taxa de falha ultrapassa 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.
Configuração de política de auditoria e 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 requisição, como informações do usuário e carimbos de data/hora. Sem corpo de requisição ou resposta. |
|
Request |
Metadados e corpo da requisição. Sem corpo de resposta. Requisições sem recurso são excluídas. |
|
RequestResponse |
Metadados da requisição, corpo da requisição e corpo da resposta. Requisições sem recurso são excluídas. |
A política de auditoria é carregada de /etc/kubernetes/audit-policy.yml nos nós mestres (via 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 no recebimento das requisições.
Requisições watch do kube-proxy, requisições GET do kubelet e de
system:nodespara nós, operações de endpoint do kube-system e requisições GET do API server para namespaces são excluídas.Operações de leitura (
get,list,watch) nas 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 API server 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 os 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óximos passos
Consulte Enable container auditing para auditar comandos
kubectl execem containers.Consulte Best security practices para práticas de segurança empresarial.