Política de auditoria

Esta página apresenta uma vista geral da política de registo de auditoria no Google Kubernetes Engine (GKE). Esta página explica como o GKE captura e regista eventos no seu cluster, os fatores que influenciam as informações registadas, onde essas informações são armazenadas e as políticas que influenciam o que vê nos seus registos de auditoria.

Para ver instruções sobre como ativar e ver os diferentes tipos de registos de auditoria, bem como as autorizações de IAM necessárias, consulte as informações de registo de auditoria do GKE.

Esta página destina-se a especialistas de segurança que procuram obter estatísticas sobre as atividades que ocorrem nos seus clusters para lhe permitir monitorizar ameaças de segurança, acompanhar alterações e resolver problemas. Para saber mais acerca das funções comuns e das tarefas de exemplo que referimos no Trusted Cloud by S3NS conteúdo, consulte o artigo Funções e tarefas comuns de utilizadores do GKE.

Antes de ler esta página, certifique-se de que conhece os seguintes tópicos:

Vista geral das políticas de auditoria

Num cluster do GKE, o servidor da API Kubernetes escreve entradas do registo de auditoria num back-end gerido pelo GKE. À medida que o GKE recebe entradas de registo do servidor da API Kubernetes, este escreve-as no registo de atividade de administrador e no registo de acesso a dados do seu projeto.

Existem duas políticas que influenciam o que vê nos registos de auditoria do seu projeto:

  • A política de auditoria do Kubernetes define regras para os eventos que são registados como entradas do registo. Também especifica os dados que as entradas do registo devem incluir.

  • A política de auditoria do GKE determina que entradas são escritas no registo de atividade do administrador e quais são escritas no registo de acesso aos dados.

Os registos de auditoria escritos no seu registo de acesso aos dados dependem da configuração do registo de auditoria. Os registos de acesso aos dados usam os preços do Google Cloud Observability. Os registos de atividade do administrador são oferecidos sem custo financeiro. O GKE suporta os seguintes tipos de registos de acesso aos dados.

  • ADMIN_READ: operações que leem metadados sobre recursos do Kubernetes, como listar pods.
  • DATA_READ: operações que leem dados em recursos do Kubernetes, como ler os registos de um pod.
  • DATA_WRITE: operações que escrevem dados em recursos do Kubernetes, como a atualização do estado do pod.

Para mais informações, consulte o artigo Configure os registos de auditoria de acesso aos dados.

Política de auditoria do Kubernetes

O servidor da API Kubernetes segue uma política especificada na flag --audit-policy-file do comando kube-apiserver.

Quando o GKE inicia o servidor da API Kubernetes, fornece um ficheiro de política de auditoria definindo o valor da flag --audit-policy-file. No repositório Kubernetes de código aberto, pode ver o script configure-helper.sh, que gera o ficheiro de política de auditoria. Pode ver a maioria do ficheiro de política de auditoria olhando diretamente para o script.

Eventos e palcos

Quando uma pessoa ou um componente faz um pedido ao servidor da API Kubernetes, o pedido passa por uma ou mais fases:

Fase Descrição
RequestReceived O controlador de auditoria recebeu o pedido.
ResponseStarted Os cabeçalhos de resposta foram enviados, mas o corpo da resposta não foi enviado.
ResponseComplete O corpo da resposta foi concluído e não vão ser enviados mais bytes.
Pânico Ocorreu um erro interno do servidor e o pedido não foi concluído.

Cada fase de um pedido gera um evento, que é processado de acordo com uma política. A política especifica se o evento deve ser registado como uma entrada de registo e, em caso afirmativo, que dados devem ser incluídos na entrada de registo.

Níveis de auditoria

O ficheiro da política de auditoria do Kubernetes contém uma lista de regras. No ficheiro de políticas, a primeira regra que corresponda a um evento define o nível de auditoria para o evento.

Uma regra pode especificar um destes níveis de auditoria:

Nível Descrição
Nenhum Não crie uma entrada de registo para o evento.
Metadados Crie uma entrada de registo. Inclua metadados, mas não inclua o corpo do pedido nem o corpo da resposta.
Pedido Crie uma entrada de registo. Incluir metadados e o corpo do pedido, mas não incluir o corpo da resposta.
RequestResponse Crie uma entrada de registo. Inclua os metadados, o corpo do pedido e o corpo da resposta.

Segue-se um exemplo de uma regra. Se um evento corresponder à regra, o servidor da API Kubernetes cria uma entrada de registo ao nível Request.

- level: Request
  userGroups: ["system:nodes"]
  verbs: ["update","patch"]
  resources:
    - group: "" # core
      resources: ["nodes/status", "pods/status"]
  omitStages:
    - "RequestReceived"

Um evento corresponde à regra se todas as seguintes afirmações forem verdadeiras:

  • O evento não corresponde a nenhuma regra anterior no ficheiro de políticas.
  • A identidade que está a fazer a chamada está no grupo de utilizadores system:nodes.
  • A chamada é um pedido update ou um pedido patch.
  • O pedido está num recurso nodes/status ou num recurso pods/status.
  • O evento não é para a fase RequestReceived da chamada.

Política de auditoria do GKE

À medida que o GKE recebe entradas de registo do servidor da API Kubernetes, aplica a sua própria política para determinar que entradas são escritas no registo de atividade de administrador do seu projeto e que entradas são escritas no registo de acesso aos dados do seu projeto.

Na maioria dos casos, o GKE aplica as seguintes regras às entradas de registo provenientes do servidor da API Kubernetes:

  • As entradas que representam pedidos create, delete e update são enviadas para o registo de atividade do administrador.

  • As entradas que representam pedidos de get, list e updateStatus são enviadas para o seu registo de acesso aos dados.

Para ver informações sobre os preços e os tipos de registos ativados por predefinição, consulte os detalhes de registo.

Ficheiro de política de auditoria do Kubernetes para clusters do GKE

Para clusters do GKE, o ficheiro de política de auditoria do Kubernetes começa com regras que especificam que determinados eventos não devem ser registados. Por exemplo, esta regra indica que qualquer pedido get por parte de kubelet num recurso nodes ou num recurso nodes/status não deve ser registado. Lembre-se de que um nível de None significa que qualquer evento correspondente não deve ser registado:

- level: None
  users: ["kubelet"] # legacy kubelet identity
  verbs: ["get"]
  resources:
    - group: "" # core
    resources: ["nodes", "nodes/status"]

Após a lista de regras level: None, o ficheiro de políticas tem uma lista de regras que são casos especiais. Por exemplo, aqui está uma regra de caso especial que indica que determinadas solicitações devem ser registadas ao nível Metadata:

- level: Metadata
    resources:
      - group: "" # core
        resources: ["secrets", "configmaps"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
    omitStages:
      - "RequestReceived"

Um evento corresponde à regra se todas as seguintes afirmações forem verdadeiras:

  • O evento não corresponde a nenhuma regra anterior no ficheiro de políticas.
  • O pedido está num recurso do tipo secrets, configmaps ou tokenreviews.
  • O evento não é para a fase RequestReceived da chamada.

Após a lista de regras de casos especiais, o ficheiro de políticas tem algumas regras gerais. Para ver as regras gerais no script, tem de substituir o valor de known_apis por ${known_apis}. Após a substituição, recebe uma regra como esta:

- level: Request
  verbs: ["get", "list", "watch"]
  resources:
    - group: "" # core
    - group: "admissionregistration.k8s.io"
    - group: "apiextensions.k8s.io"
    - group: "apiregistration.k8s.io"
    - group: "apps"
    - group: "authentication.k8s.io"
    - group: "authorization.k8s.io"
    - group: "autoscaling"
    - group: "batch"
    - group: "certificates.k8s.io"
    - group: "extensions"
    - group: "metrics.k8s.io"
    - group: "networking.k8s.io"
    - group: "policy"
    - group: "rbac.authorization.k8s.io"
    - group: "settings.k8s.io"
    - group: "storage.k8s.io"
  omitStages:
    - "RequestReceived"

A regra aplica-se a eventos que não correspondem a nenhuma regra anterior no ficheiro de políticas e não estão na fase RequestReceived. A regra indica que os pedidos get, list e watch em qualquer recurso pertencente a um dos grupos indicados devem ser registados ao nível Request.

A regra seguinte no ficheiro de políticas tem o seguinte aspeto:

- level: RequestResponse
  resources:
    - group: "" # core
    - group: "admissionregistration.k8s.io"
    - group: "apiextensions.k8s.io"
    - group: "apiregistration.k8s.io"
    - group: "apps"
    - group: "authentication.k8s.io"
    - group: "authorization.k8s.io"
    - group: "autoscaling"
    - group: "batch"
    - group: "certificates.k8s.io"
    - group: "extensions"
    - group: "metrics.k8s.io"
    - group: "networking.k8s.io"
    - group: "policy"
    - group: "rbac.authorization.k8s.io"
    - group: "settings.k8s.io"
    - group: "storage.k8s.io"
  omitStages:
    - "RequestReceived"

A regra aplica-se a eventos que não correspondem a nenhuma regra anterior no ficheiro de políticas e não estão na fase RequestReceived. Em particular, a regra não se aplica aos pedidos de leitura: get, list e watch. Em alternativa, a regra aplica-se a pedidos de escrita, como create, update e delete. A regra indica que os pedidos de gravação devem ser registados ao nível RequestResponse.

Resumo da política de auditoria do Kubernetes para clusters do GKE

A lista seguinte resume a política de auditoria do Kubernetes para clusters do GKE:

  • Em geral, os pedidos de escrita, como create, update e delete, são registados ao nível RequestResponse.

  • Em geral, os eventos get, list e watch são registados ao nível de Metadata.

  • Alguns eventos são tratados como casos especiais. Para ver uma lista definitiva de pedidos que são tratados como casos especiais, consulte o script da política. Os casos especiais incluem o seguinte:

    • Os pedidos de atualização e aplicação de patches por kubelet, system:node-problem-detector ou system:serviceaccount:kube-system:node-problem-detector num recurso nodes/status ou num recurso pods/status são registados ao nível do pedido.

    • Os pedidos de atualização e aplicação de patches por qualquer identidade no grupo system:nodes num recurso nodes/status ou num recurso pods/status são registados ao nível do pedido.

    • Os pedidos deletecollection de system:serviceaccount:kube-system:namespace-controller são registados ao nível do pedido.

    • Os pedidos num recurso secrets, num recurso configmaps ou num recurso tokenreviews são registados ao nível dos metadados.

  • Determinados pedidos não são registados. Para uma lista definitiva de pedidos que não são registados, consulte as regras no level: Nonescript da política. Os seguintes pedidos não são registados:

    • Pedidos por parte de system:kube-proxy para ver um recurso endpoints, um recurso services ou um recurso services/status.

    • Receba pedidos por system:unsecured num recurso configmaps no espaço de nomes kube-system.

    • Receba pedidos por kubelet num recurso nodes ou num recurso nodes/status.

    • Receber pedidos por qualquer identidade no grupo system:nodes num recurso nodes ou num recurso nodes/status.

    • Receba e atualize pedidos por system:kube-controller-manager, system:kube-scheduler ou system:serviceaccount:endpoint-controller num recurso endpoints no espaço de nomes kube-system.

    • Receba pedidos por system:apiserver num recurso namespaces, num recurso namespaces/status ou num recurso namespaces/finalize.

    • Obter e listar pedidos por system:kube-controller-manager em qualquer recurso no grupo metrics.k8s.io.

    • Pedidos a URLs que correspondem a /healthz*, /version ou /swagger*.

O que se segue?