Política de auditoria

Nesta página, você verá a política de geração de registros de auditoria do Google Kubernetes Engine (GKE). Para instruções sobre como ativar e visualizar os diferentes tipos de registros de auditoria, bem como as permissões necessárias do IAM, consulte Informações sobre a geração de registros de auditoria do GKE.

Antes de começar

Antes de ler este documento, você precisa conhecer esses tópicos:

Visão geral

Em um cluster do GKE, o servidor da API Kubernetes grava entradas de registro de auditoria em um back-end que é gerenciado pelo GKE. Como o GKE recebe entradas de registro do servidor da API Kubernetes, ele as grava nos registros de atividades do administrador e de acesso a dados do projeto.

Há duas políticas que influenciam o que você vê nos registros de auditoria do seu projeto:

  • A política de auditoria do Kubernetes define regras para as quais os eventos são gravados como entradas de registro. Também especifica quais dados são incluídos nas entradas de registro.

  • A política de auditoria do Kubernetes Engine determina quais entradas são gravadas no seu registro de atividades do administrador e quais são gravadas no seu registro de acesso a dados.

Os registros de auditoria gravados no seu registro de acesso a dados dependem da configuração de registros de auditoria. Os registros de acesso a dados usam os preços de observabilidade do Google Cloud. Os registros de atividade do administrador são oferecidos sem custos financeiros. O GKE aceita os seguintes tipos de registros de acesso a dados.

  • ADMIN_READ: operações que leem metadados sobre recursos do Kubernetes, como listagem de pods.
  • DATA_READ: operações que leem dados em recursos do Kubernetes, como a leitura dos registros de um pod.
  • DATA_WRITE: operações que gravam dados nos recursos do Kubernetes, como a atualização do status do pod.

Para mais informações, veja Como configurar os registros de auditoria de acesso a dados.

Política de auditoria do Kubernetes

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

Quando o GKE inicia o servidor da API Kubernetes, ele fornece um arquivo da política de auditoria definindo o valor da sinalização --audit-policy-file. No repositório Kubernetes de código aberto, é possível ver o script configure-helper.sh, que gera o arquivo da política de auditoria. É possível ver diretamente no script a maior parte do arquivo da política de auditoria.

Eventos e etapas

Quando uma pessoa ou um componente faz uma solicitação ao servidor da API Kubernetes, essa solicitação passa por uma ou mais etapas:

Fase Descrição
RequestReceived O gerenciador de auditoria recebeu a solicitação.
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 nenhum outro byte será enviado.
Panic Houve um erro interno no servidor e a solicitação não foi concluída.

Cada estágio de uma solicitação gera um evento, que é processado de acordo com uma política. A política especifica se o evento será gravado como uma entrada de registro e, em caso afirmativo, quais dados serão incluídos nessa entrada.

Níveis de auditoria

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

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

Nível Descrição
Nenhum Não criar uma entrada de registro para o evento.
Metadados Criar uma entrada de registro. Incluir os metadados, mas não incluir o corpo da solicitação ou da resposta.
Solicitação Criar uma entrada de registro. Incluir os metadados e o corpo da solicitação, mas não incluir o corpo da resposta.
RequestResponse Criar uma entrada de registro. Incluir os metadados, o corpo da solicitação e o corpo da resposta.

Aqui está um exemplo de uma regra. Se um evento corresponder à regra, o servidor da API Kubernetes criará uma entrada de registro no nível Request.

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

Um evento corresponderá à regra se todos os itens a seguir forem verdadeiros:

  • O evento não corresponde a nenhuma regra anterior no arquivo da política.
  • A identidade que faz a chamada está no grupo de usuários system:nodes.
  • A chamada é uma solicitação update ou patch.
  • A solicitação está em um recurso nodes/status ou em um recurso pods/status.
  • O evento não é para a etapa RequestReceived da chamada.

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

  • Em geral, solicitações de gravação como create, update e delete são registradas no nível RequestResponse.

  • Em geral, os eventos get, list e watch são registrados no nível Metadata.

  • Alguns eventos são tratados como casos especiais. Para ver uma lista definitiva de solicitações tratadas como casos especiais, consulte o script da política. No momento, estes são os casos especiais:

    • Solicitações de atualização e patch por kubelet, system:node-problem-detector ou system:serviceaccount:kube-system:node-problem-detector em um recurso nodes/status ou um recurso pods/status são registradas no nível da Solicitação.

    • As solicitações de atualização e patch por qualquer identidade no grupo system:nodes em um recurso nodes/status ou em um recurso pods/status são registradas no nível da Solicitação.

    • Solicitações deletecollection de system:serviceaccount:kube-system:namespace-controller são registradas no nível da Solicitação.

    • As solicitações em um recurso secrets, configmaps ou tokenreviews são registradas no nível de metadados.

  • Algumas solicitações não são registradas. Para uma lista definitiva de solicitações que não são registradas, consulte as regras de level: None no script da política. No momento, estas são as solicitações que não são registradas:

    • Solicitações feitas por system:kube-proxy para assistir a um recurso endpoints, services ou um recurso services/status.

    • Solicitações de recebimento feitas por system:unsecured em um recurso configmaps no namespace kube-system.

    • Solicitações de recebimento feitas por kubelet em um recurso nodes ou em um recurso nodes/status.

    • Solicitações de recebimento feitas por qualquer identidade no grupo system:nodes em um recurso nodes ou em um recurso nodes/status.

    • Solicitações de recebimento e atualização feitas por system:kube-controller-manager, system:kube-scheduler ou system:serviceaccount:endpoint-controller em um recurso endpoints no namespace kube-system.

    • Solicitações de recebimento feitas por system:apiserver em um recurso namespaces, um recurso namespaces/status ou um recurso namespaces/finalize.

    • Solicitações de recebimento e listagem feitas por system:kube-controller-manager em qualquer recurso no grupo metrics.k8s.io.

    • Solicitações de URLs que correspondem a /healthz*, /version ou /swagger*.

Política de auditoria do GKE

GKE medida que o GKE recebe entradas de registro do servidor da API Kubernetes, ele aplica uma política própria para determinar quais entradas são gravadas no registro de atividades do administrador do projeto e quais são gravadas no registro de acesso a dados do projeto.

Na maioria das vezes, o Kubernetes Engine aplica as seguintes regras para registrar entradas provenientes do servidor da API Kubernetes:

  • As entradas que representam solicitações create, delete e update vão para seu registro de atividades do administrador.

  • Entradas que representam solicitações get, list e updateStatus vão para seu registro de acesso a dados.

Para mais informações sobre preços e quais tipos de registro estão ativados por padrão, consulte Detalhes do Logging.

Noções básicas sobre o arquivo da política de auditoria do Kubernetes

Para clusters do Kubernetes Engine, o arquivo da política de auditoria do Kubernetes começa com regras que especificam que determinados eventos não serão registrados. Por exemplo, essa regra diz que qualquer solicitação get feita por kubelet em um recurso nodes ou um recurso nodes/status não será registrada. Lembre-se de que um nível None significa que qualquer evento correspondente não será registrado:

- 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 arquivo de política tem uma lista de regras que são casos especiais. Por exemplo, veja uma regra de caso especial que diz para registrar certas solicitações no nível Metadata:

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

Um evento corresponderá à regra se todos os itens a seguir forem verdadeiros:

  • O evento não corresponde a nenhuma regra anterior no arquivo da política.
  • A solicitação está em um recurso do tipo secrets, configmaps ou tokenreviews.
  • O evento não é para a etapa RequestReceived da chamada.

Após a lista de regras de casos especiais, o arquivo da política tem algumas regras gerais. Para ver as regras gerais no script, é necessário substituir o valor de known_apis por ${known_apis}. Após a substituição, você gera 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 se aplica a eventos que não correspondem a nenhuma regra anterior no arquivo de política e não estão no cenário RequestReceived. A regra informa que as solicitações get, list e watch de qualquer recurso pertencente a um dos grupos listados devem ser registradas no nível Request.

A próxima regra no arquivo da política é assim:

- 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 se aplica a eventos que não correspondem a nenhuma regra anterior no arquivo de política e não estão no cenário RequestReceived. Em particular, a regra não se aplica às solicitações de leitura: get, list e watch. Em vez disso, a regra se aplica a solicitações de gravação como create, update e delete. A regra diz que as solicitações de gravação devem ser registradas no nível RequestResponse.

A seguir