Visão geral
Os clusters do Anthos no VMware (GKE no local) usam o Kubernetes Audit Logging, que mantém um registro cronológico das chamadas feitas ao servidor da API Kubernetes de um cluster. Os registros de auditoria são úteis para investigar solicitações de API suspeitas e coletar estatísticas.
Antes do Anthos 1.2, os clusters do Anthos no VMware gravavam registros de auditoria apenas no disco. O Anthos 1.2 introduz um recurso Alfa que permite que os registros de auditoria sejam gravados nos registros de auditoria do Cloud em um projeto do Google Cloud. A gravação em registros de auditoria do Cloud tem vários benefícios em relação à gravação em disco ou até mesmo à captura de registros em um sistema de geração de registros no local:
- Os registros de auditoria de todos os clusters do Anthos podem ser centralizados.
- As entradas de registro gravadas nos registros de auditoria do Cloud são imutáveis.
- As entradas de registros de auditoria do Cloud são mantidas por 400 dias.
- Os registros de auditoria do Cloud estão incluídos no preço do Anthos.
É possível configurar os clusters do Anthos no VMware para gravar registros no disco ou nos registros de auditoria do Cloud.
Geração de registros de auditoria baseada em disco
Por padrão, os registros de auditoria do GKE On-Prem são gravados em um disco permanente para que as reinicializações e upgrades de VMs não façam com que os registros desapareçam. Os clusters do Anthos no VMware mantêm até 12 GB de entradas de registro de auditoria.
Registros de auditoria do Cloud
Se os registros de auditoria do Cloud estiverem ativados, as entradas de registro de auditoria referentes à atividade do administrador de todos os servidores da API Kubernetes serão enviadas ao Google Cloud, usando o projeto e o local que você especificar ao criar um cluster de usuário. Quando você ativa os registros de auditoria do Cloud, o GKE On-Prem desativa a geração de registros de auditoria baseados em disco.
Para armazenar em buffer e gravar entradas de registro nos registros de auditoria do Cloud, os clusters do Anthos no VMware implantam um pod audit-proxy
no cluster de administrador.
Esse pod também está disponível como um contêiner de arquivo secundário nos clusters do usuário.
Limitações
Os registros de auditoria do Cloud para o GKE On-Prem são um recurso Alfa. Esta versão Alfa tem várias limitações:
A geração de registros de acesso a dados não é compatível.
Não é possível modificar a política de auditoria do Kubernetes.
Os registros de auditoria do Cloud não são resilientes a interrupções de rede. Se não for possível exportar as entradas de registro para o Google Cloud, elas serão descartadas.
Como ativar a API Anthos GKE e a API Anthos Audit
Para usar os registros de auditoria do Cloud com o GKE On-Prem, faça o seguinte:
Se você estiver no Anthos 1.4.x ou anterior, ative a API Anthos GKE.
Se você estiver no Anthos 1.5 ou posterior, ative a API Anthos Audit.
Se você não tiver certeza, ou se estiver planejando fazer o upgrade para o Anthos 1.5, ative os dois.
Como criar uma conta de serviço para Registros de auditoria do Cloud
Você já tem várias contas de serviço criadas para usar com o GKE On-Prem. Para este recurso Alfa, é necessário criar uma conta de serviço e colocá-la na lista de permissões.
Crie sua conta de serviço dos registros de auditoria do Cloud:
gcloud iam service-accounts create audit-logging-service-account
Crie um arquivo de chave JSON para sua conta de serviço dos registros de auditoria do Cloud:
gcloud iam service-accounts keys create audit-logging-key.json \ --iam-account AUDIT_LOGGING_SERVICE_ACCOUNT_EMAIL
em que AUDIT_LOGGING_SERVICE_ACCOUNT_EMAIL é o endereço de e-mail da sua conta de serviço.
Salve
audit-logging-key.json
na estação de trabalho do administrador no mesmo local que as outras chaves da conta de serviço.
Como permitir a listagem da sua conta de serviço
Para solicitar que sua conta de serviço de registros de auditoria do Cloud seja adicionada à lista de permissões, preencha o formulário Alfa de registros de auditoria do Cloud para clusters do Anthos no VMware. Você receberá um e-mail de notificação quando a lista de permissões for concluída. Sua conta de serviço precisa estar na lista de permissões antes de você criar um cluster de administrador ou um cluster de usuário que ative os registros de auditoria do Cloud.
Como criar um cluster de administrador com os Registros de auditoria do Cloud ativados
Você só pode ativar os Registros de auditoria do Cloud para um cluster de administrador quando cria o cluster de administrador. Não é possível modificar um cluster de administrador atual para ativar os Registros de auditoria do Cloud.
Consulte as instruções sobre Como criar um cluster de administração.
Depois de executar
gkectl create-config
, preencha o arquivo de configuração normalmente, mas também preencha a nova seçãoadmin-cluster.yaml
emcloudAuditLogging
.Defina
cloudAuditLogging.projectId
como o ID do projeto do Google Cloud em que você quer ver os Registros de auditoria relacionados ao cluster de administrador.Defina
cloudAuditLogging.clusterLocation
como uma região do Google Cloud em que você quer armazenar registros de auditoria. Para melhorar a latência, escolha uma região próxima ao seu data center local.Defina
cloudAuditLogging.serviceAccountKeyPath
como o caminho do arquivo de chave JSON para sua conta de serviço dos registros de auditoria do Cloud.
Exemplo:
cloudAuditLogging: projectId: "my-project" clusterLocation: "us-west1" serviceAccountKeyPath: "/my-key-folder/audit-logging-key.json"
Continue a criação do cluster normalmente.
Como criar um cluster de usuário com registros de auditoria do Cloud ativados
Caso você ainda não tenha criado um cluster de administrador, consulte as instruções Como criar um cluster de administrador.
Se você já tiver um cluster de administrador, crie um novo cluster de usuário seguindo as instruções em Como criar clusters de usuário extras.
Depois de executar
gkectl create-config
, preencha o arquivo de configuração normalmente, mas também preencha a nova seçãouser-cluster.yaml
emcloudAuditLogging
.Defina
cloudAuditLogging.projectId
como o ID do projeto do Google Cloud em que você quer visualizar os registros de auditoria que pertencem ao cluster de usuário.Defina
cloudAuditLogging.clusterLocation
como uma região do Google Cloud em que você quer armazenar registros de auditoria. É uma boa ideia escolher uma região próxima ao data center no local.Defina
cloudAuditLogging.serviceAccounKeyPath
como o caminho do arquivo de chave JSON para sua conta de serviço dos registros de auditoria do Cloud.
Exemplo:
cloudAuditLogging: projectId: "my-project" clusterLocation: "us-west1" serviceAccountKeyPath: "/my-key-folder/audit-logging-key.json"
Continue a criação do cluster normalmente.
Como ativar registros de auditoria do Cloud em um cluster de usuário atual
Os registros de auditoria do Cloud podem ser ativados em um cluster de usuário atual usando o
comando
gkectl update cluster
.
Preencha a seção cloudAuditLogging
do
arquivo
user-cluster.yaml
. Consulte
Como criar um cluster de usuário com os registros de auditoria do Cloud ativados
para ver detalhes sobre os campos individuais.
Depois, execute:
gkectl update cluster --config [USER_CLUSTER_YAML] --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]
Como ativar registros de auditoria do Cloud em um cluster de usuário atual
Abra o arquivo
user-cluster.yaml
que descreve seu cluster de usuário.Exclua ou comente a seção
cloudAuditLogging
e salve o arquivo.Execute este comando para atualizar o cluster de usuário:
gkectl update cluster --config [USER_CLUSTER_YAML] --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]
Como acessar clusters do Anthos nos registros de auditoria da VMware
Geração de registros de auditoria baseada em disco
Veja os servidores da API Kubernetes em execução no cluster de administrador e todos os clusters de usuário associados:
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] get pods --all-namespaces -l component=kube-apiserver
em que [ADMIN_CLUSTER_KUBECONFIG] é o arquivo kubeconfig do cluster de administrador.
Faça o download dos registros de auditoria do servidor da API:
kubectl cp -n [NAMESPACE] [APISERVER_POD_NAME]:/var/log/kube-audit/kube-apiserver-audit.log /tmp/kubeaudit.log
Esse comando busca o arquivo de registro mais recente, que pode conter até 1 GB de dados para o cluster de administrador e até 850 GB para clusters de usuário.
Também é possível encontrar os registros de auditoria do cluster de administração nos nós do plano de controle em
/var/log/kube-audit/kube-apiserver-audit.log
. Os registros de auditoria do cluster do usuário estão noPersistentVolumeClaim
chamadokube-audit-kube-apiserver-0
. É possível acessar esses dados dentro dos seus próprios pods usando entradasvolume
como esta:volumes: ‐ name: kube-audit hostPath: path: /var/log/kube-audit type: ""
volumes: ‐ name: kube-audit persistentVolumeClaim: claimName: kube-audit-kube-apiserver-0 readOnly: true
Para programar seu pod no nó apropriado do cluster de administrador (e somente neste nó), você precisará adicionar seções
nodeSelector
etolerations
à especificação do pod, como esta:spec: nodeSelector: node-role.kubernetes.io/master: '' tolerations: ‐ key: node-role.kubernetes.io/master value: "" effect: NoSchedule
Para o cluster de usuários, use este
nodeSelector
:spec: nodeSelector: kubernetes.googleapis.com/cluster-name: [USER_CLUSTER_NAME]
Registros de auditoria mais antigos são mantidos em arquivos separados. Para visualizar esses arquivos:
kubectl exec -n [NAMESPACE] [APISERVER_POD_NAME] -- ls /var/log/kube-audit -la
O nome de arquivo de cada registro de auditoria tem um carimbo de data/hora que indica quando o arquivo foi alternado. Cada arquivo inclui registros de auditoria até esse horário e data.
Registros de auditoria do Cloud
Console
No Console do Cloud, acesse a página Registros no menu Geração de registros.
Na caixa Filtrar por rótulo ou pesquisa de texto, logo acima dos menus suspensos discutidos anteriormente, clique na seta para baixo para abrir o menu suspenso. No menu, escolha Converter para filtro avançado.
Preencha a caixa de texto com o filtro a seguir:
resource.type="k8s_cluster" logName="projects/[PROJECT_ID]/logs/externalaudit.googleapis.com%2Factivity" protoPayload.serviceName="anthosgke.googleapis.com"
Clique em Enviar filtro para exibir todos os registros de auditoria dos clusters do Anthos em clusters do VMware que foram configurados para fazer login nesse projeto.
gcloud
Liste as duas primeiras entradas no registro de atividade do administrador do projeto que se aplicam ao tipo de recurso k8s_cluster
:
gcloud logging read \ 'logName="projects/[PROJECT_ID]/logs/externalaudit.googleapis.com%2Factivity" \ AND resource.type="k8s_cluster" \ AND protoPayload.serviceName="anthosgke.googleapis.com" ' \ --limit 2 \ --freshness 300d
[PROJECT_ID] é o ID do projeto.
A saída mostra duas entradas de registro. Observe que, para cada entrada de registro, o
campo logName
tem o valor
projects/[PROJECT_ID]/logs/externalaudit.googleapis.com%2Factivity
,
e protoPayload.serviceName
é igual a anthosgke.googleapis.com
.
Política de auditoria
O comportamento dos Registros de auditoria do Cloud é determinado por uma política de registro de auditoria do Kubernetes configurada estaticamente. No momento, não é possível alterar essa política, mas ela estará disponível em uma versão futura.