|
Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official. |
Habilitando o Log de Auditoria da API em Clusters Downstream
A auditoria do Kubernetes fornece um conjunto de registros cronológicos relevantes para a segurança sobre um cluster. O kube-apiserver realiza a auditoria. As solicitações geram um evento em cada etapa de sua execução, que é então pré-processado de acordo com uma determinada política e gravado em um backend. A política determina o que é registrado e o backend persiste os registros.
Você pode querer configurar o log de auditoria como parte da conformidade com os controles do Centro de Segurança da Internet (CIS) para o Kubernetes Benchmark.
Para detalhes de configuração, consulte a documentação oficial do Kubernetes.
-
RKE2
-
K3s
Método 1 (Recomendado): Defina `audit-policy-file` em `machineGlobalConfig` ou `machineSelectorConfig`
Você pode definir audit-policy-file no arquivo de configuração usando machineGlobalConfig ou machineSelectorConfig.
Ao usar machineGlobalConfig, o Rancher entrega o arquivo no caminho /var/lib/rancher/rke2/etc/config-files/audit-policy-file em todos os nós (tanto nos nós do plano de controle quanto nos nós de trabalho) e define as opções adequadas no servidor RKE2. Isso pode causar uma reconciliação indesejada dos nós de trabalho quando a política de auditoria é modificada.
Para evitar a reconciliação dos nós de trabalho, use machineSelectorConfig com um seletor de rótulos para direcionar apenas os nós do plano de controle. Isso garante que o arquivo da política de auditoria seja entregue apenas aos nós do plano de controle.
Exemplo usando machineGlobalConfig:
apiVersion: provisioning.cattle.io/v1
kind: Cluster
spec:
rkeConfig:
machineGlobalConfig:
audit-policy-file: |
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
resources:
- group: ""
resources:
- pods
Exemplo usando machineSelectorConfig (recomendado para evitar a reconciliação dos nós de trabalho):
apiVersion: provisioning.cattle.io/v1
kind: Cluster
spec:
rkeConfig:
machineSelectorConfig:
- config:
audit-policy-file: |
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
resources:
- group: ""
resources:
- pods
machineLabelSelector:
matchLabels:
rke.cattle.io/control-plane-role: 'true'
Método 2: Use as Diretrizes, `machineSelectorFiles` e `machineGlobalConfig`
|
Este recurso está disponível no Rancher v2.7.2 e versões posteriores. |
Você pode usar machineSelectorFiles para entregar o arquivo da política de auditoria aos nós do plano de controle, e machineGlobalConfig para definir as opções no kube-apiserver.
Como pré-requisito, você deve criar um segredo ou configmap para ser a fonte da política de auditoria.
O segredo ou configmap deve atender aos seguintes requisitos:
-
Deve estar no namespace
fleet-defaultonde o objeto Cluster existe. -
Deve ter a anotação
rke.cattle.io/object-authorized-for-clusters: <cluster-name1>,<cluster-name2>, que permite que os clusters de destino o utilizem.
|
O Rancher Dashboard fornece um formulário fácil de usar para criar o segredo ou configmap. |
Exemplo:
apiVersion: v1
data:
audit-policy: >-
IyBMb2cgYWxsIHJlcXVlc3RzIGF0IHRoZSBNZXRhZGF0YSBsZXZlbC4KYXBpVmVyc2lvbjogYXVkaXQuazhzLmlvL3YxCmtpbmQ6IFBvbGljeQpydWxlczoKLSBsZXZlbDogTWV0YWRhdGE=
kind: Secret
metadata:
annotations:
rke.cattle.io/object-authorized-for-clusters: cluster1
name: <name1>
namespace: fleet-default
Ative e configure o registro de auditoria editando o cluster em YAML e utilizando as diretivas machineSelectorFiles e machineGlobalConfig.
Exemplo:
apiVersion: provisioning.cattle.io/v1
kind: Cluster
spec:
rkeConfig:
machineGlobalConfig:
kube-apiserver-arg:
- audit-policy-file=<customized-path>/dev-audit-policy.yaml
- audit-log-path=<customized-path>/dev-audit.logs
machineSelectorFiles:
- fileSources:
- configMap:
name: ''
secret:
items:
- key: audit-policy
path: <customized-path>/dev-audit-policy.yaml
name: dev-audit-policy
machineLabelSelector:
matchLabels:
rke.cattle.io/control-plane-role: 'true'
Para mais informações sobre a configuração do cluster, consulte as páginas de referência de configuração do cluster RKE2.
|
Este recurso está disponível no Rancher v2.7.2 e versões posteriores. |
Você pode usar machineSelectorFiles para entregar o arquivo da política de auditoria aos nós do plano de controle, e machineGlobalConfig para definir as opções no kube-apiserver.
Como pré-requisito, você deve criar um segredo ou configmap para ser a fonte da política de auditoria.
O segredo ou configmap deve atender aos seguintes requisitos:
-
Deve estar no namespace
fleet-defaultonde o objeto Cluster existe. -
Deve ter a anotação
rke.cattle.io/object-authorized-for-clusters: <cluster-name1>,<cluster-name2>, que permite que os clusters de destino o utilizem.
Exemplo:
apiVersion: v1
data:
audit-policy: >-
IyBMb2cgYWxsIHJlcXVlc3RzIGF0IHRoZSBNZXRhZGF0YSBsZXZlbC4KYXBpVmVyc2lvbjogYXVkaXQuazhzLmlvL3YxCmtpbmQ6IFBvbGljeQpydWxlczoKLSBsZXZlbDogTWV0YWRhdGE=
kind: Secret
metadata:
annotations:
rke.cattle.io/object-authorized-for-clusters: cluster1
name: <name1>
namespace: fleet-default
Ative e configure o registro de auditoria editando o cluster em YAML e utilizando as diretivas machineSelectorFiles e machineGlobalConfig.
Exemplo:
apiVersion: provisioning.cattle.io/v1
kind: Cluster
spec:
rkeConfig:
machineGlobalConfig:
kube-apiserver-arg:
- audit-policy-file=<customized-path>/dev-audit-policy.yaml
- audit-log-path=<customized-path>/dev-audit.logs
machineSelectorFiles:
- fileSources:
- configMap:
name: ''
secret:
items:
- key: audit-policy
path: <customized-path>/dev-audit-policy.yaml
name: dev-audit-policy
machineLabelSelector:
matchLabels:
rke.cattle.io/control-plane-role: 'true'
Para mais informações sobre a configuração do cluster, consulte as páginas de referência de configuração do cluster K3s.