Política de auditoria

Nesta página, descrevemos a política de geração de registros de auditoria do Google Kubernetes Engine.

Antes de começar

Antes de ler este documento, familiarize-se com o material destes tópicos:

Visão geral

Em um cluster do Kubernetes Engine, o servidor da API Kubernetes grava as entradas do registro de auditoria em um back-end que é gerenciado pelo Kubernetes Engine. Como o Kubernetes Engine 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.

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 Kubernetes Engine inicia o servidor da API Kubernetes, ele fornece um arquivo de política de auditoria definindo o valor da sinalização --audit-policy-file. No repositório Kubernetes de código aberto, você pode 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:

Etapa 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
None Não criar uma entrada de registro para o evento.
Metadata Criar uma entrada de registro. Incluir os metadados, mas não incluir o corpo da solicitação ou da resposta.
Request 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 da 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 pods/status.
  • O evento não é voltado à etapa RequestReceived da chamada.

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

  • 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:

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

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

    • As solicitações deletecollection feitas por system:serviceaccount:kube-system:namespace-controller são registradas no nível Request.

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

  • Algumas solicitações não são registradas. Para ver uma lista definitiva de solicitações que não são registradas, consulte as regras 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 observar um recurso endpoints, services ou 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 nodes/status

    • solicitações de recebimento feitas por qualquer identidade no grupo system:nodes em um recurso nodes ou 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, namespaces/status ou namespaces/finalize

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

    • solicitações para URLs que correspondam a /healthz*, /version ou /swagger*

Política de auditoria do Kubernetes Engine

À medida que o Kubernetes Engine 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 o registro de atividades do administrador.

  • As entradas que representam solicitações get, list e updateStatus vão para 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, esta regra diz que qualquer solicitação get feita por kubelet em um recurso nodes ou nodes/status não será registrada. Lembre-se de que, no nível None, nenhum evento correspondente 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 da política tem uma lista de regras que são casos especiais. Por exemplo, aqui está uma regra de caso especial que diz para registrar determinadas 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 é voltado à 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, substitua 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 da política e não estão na etapa RequestReceived. A regra diz que as solicitações get, list e watch em qualquer recurso pertencente a um dos grupos listados serão 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 da política e não estão na etapa 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 serão registradas no nível RequestResponse.

Próximas etapas

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Kubernetes Engine