Esta página foi traduzida pela API Cloud Translation.

Política de auditoria

Autopilot Standard

Neste documento, descrevemos a política de geração de registros de auditoria no Google Kubernetes Engine (GKE). Este documento pressupõe que você conheça o seguinte:

O GKE captura e registra eventos no cluster, e vários fatores influenciam quais informações são registradas, onde elas são armazenadas e as políticas que influenciam o que você vê nos registros de auditoria.

Este documento é destinado a especialistas em segurança que querem entender as atividades nos clusters para monitorar ameaças, acompanhar mudanças e resolver problemas. Para saber mais sobre papéis comuns e tarefas de exemplo mencionados no conteúdo do Google Cloud , consulte Tarefas e funções de usuário comuns do GKE.

Para saber como ativar e visualizar os diferentes tipos de registros de auditoria e as permissões necessárias do IAM, consulte Informações sobre a geração de registros de auditoria do GKE.

Visão geral das políticas de auditoria

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.

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.

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

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.

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

A lista a seguir resume a 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. Os casos especiais incluem o seguinte:
- 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. As seguintes solicitações 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*.