Política de auditoria

Nesta página, você verá 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 de 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 quais 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 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 (em inglês), 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. Inclui os metadados, mas não inclui o corpo da solicitação ou da resposta.
Request Criar uma entrada de registro. Inclui os metadados e o corpo da solicitação, mas não inclui o corpo da resposta.
RequestResponse Criar uma entrada de registro. Inclui 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 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 uma lista definitiva de solicitações tratadas como casos especiais, consulte o script da política (em inglês). 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 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 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 (em inglês). 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 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 de URLs que correspondem 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 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 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 nodes/status não será registrada. Lembre-se de que um nível de 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 da 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 (em inglês), é necessário substituir o valor de known_apis por ${known_apis}. Após a substituição, uma regra como esta surgirá:

    - 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 no estágio RequestReceived. A regra informa que as solicitações get, list e watch de qualquer recurso pertencente a um dos grupos listados precisam 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 da política e não estão no estágio 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 precisam ser registradas no nível RequestResponse.

A seguir