Utilizando Log Analytics para monitorar logs de auditoria do Azure RedHat OpenShift

Posted September 6, 20231 yr

Utilizando Log Analytics para monitorar logs de auditoria do Azure RedHat OpenShift

Introdução

Por padrão, os clusters Azure Red Hat OpenShift possuem uma forma de monitorar os logs de auditoria através do OpenShift Logging, que envolve a instalação do OpenShift Elasticsearch Operator e OpenShift Cluster Logging. Embora essa solução seja eficiente, ela não permite a integração com o Azure Monitor, a solução de monitoramento da Microsoft, nem a centralização dos logs de auditoria de diversos clusters em um único local.

Para demonstrarmos uma solução personalizada, é necessário possuir um cluster Azure Red Hat OpenShift. Caso você não possua um cluster, é possível seguir o tutorial Criando um cluster Azure Red Hat OpenShift e lembre-se de utilizar a opção do pull secret para baixar as imagens da RedHat Pull Secret

Pré-requisitos

Ter um cluster Azure Red Hat OpenShift criado Criando um cluster Azure Red Hat OpenShift
Ter oc client instalado instalando o oc client
Ter o kubeclt instalado instalando o kubeclt
Ter o Azure Cli instalado instalando o Azure Cli
Ter o Helm Charts instalado instalando o Helm Charts

Fluent Bit

Fluent Bit é um sistema de coleta e encaminhamento de registros e logs (logs de eventos e mensagens) desenvolvido como parte do ecossistema Fluentd. É uma solução leve e eficiente projetada para coletar, filtrar e encaminhar logs em ambientes distribuídos.

Azure Red Hat OpenShift

Após a criação do cluster, vamos analisar as pastas que estão os logs de auditoria do cluster.

Faça o login no cluster, você pode pegar o endereço do cluster no portal do Azure, na aba Overview do cluster criado e clicando no botão Connect
Clique na URL e utilize o username kubeadmin como user e o password como senha.

Instalando o Fluent Bit no cluster

Para fazer a instalação no Azure Red Hat OpenShift, precisamos setar o security context constraints (SCC), para isso você precisa estar logado via cli e ter um usuário com permissão de cluster-admin.

Execute o comando abaixo para criar o SCC:

kubectl create -f https://raw.githubusercontent.com/fluent/fluent-bit-kubernetes-logging/master/fluent-bit-openshift-security-context-constraints.yaml

A instalação do Fluent Bit é feita via helm charts, para isso, vamos adicionar o repositório do helm charts do Fluent Bit:

helm repo add fluent Fluent Helm Repository

Por padrão a instalação do Fluent Bit os DaemonSets são instalados somente nos workers nodes, mas para ter acesso aos logs de auditoria, precisamos fazer a instalação somente no master node, para isso, vamos criar um arquivo chamado values.yaml com o seguinte conteúdo:

# kind -- DaemonSet or Deployment

kind: DaemonSet

# replicaCount -- Only applicable if kind=Deployment

replicaCount: 1

image:

repository: cr.fluentbit.io/fluent/fluent-bit

# Overrides the image tag whose default is {{ .Chart.AppVersion }}

tag: "latest-debug"

pullPolicy: Always

testFramework:

enabled: true

image:

repository: busybox

pullPolicy: Always

tag: latest

imagePullSecrets: []

nameOverride: ""

fullnameOverride: ""

serviceAccount:

create: true

annotations: {}

name:

rbac:

create: true

nodeAccess: false

# Configure podsecuritypolicy

# Ref: Pod Security Policies

# from Kubernetes 1.25, PSP is deprecated

# See: Kubernetes v1.25: Combiner

# We automatically disable PSP if Kubernetes version is 1.25 or higher

podSecurityPolicy:

create: false

annotations: {}

openShift:

# Sets Openshift support

enabled: true

# Creates SCC for Fluent-bit when Openshift support is enabled

securityContextConstraints:

create: true

annotations: {}

podSecurityContext: {}

# fsGroup: 2000

hostNetwork: false

dnsPolicy: ClusterFirst

dnsConfig: {}

# nameservers:

# - 1.2.3.4

# searches:

# - ns1.svc.cluster-domain.example

# - my.dns.search.suffix

# options:

# - name: ndots

# value: "2"

# - name: edns0

hostAliases: []

# - ip: "1.2.3.4"

# hostnames:

# - "foo.local"

# - "bar.local"

securityContext:

privileged: true

runAsUser: 0

readOnlyRootFilesystem: false

# capabilities:

# drop:

# - ALL

# readOnlyRootFilesystem: true

# runAsNonRoot: true

# runAsUser: 1000

service:

type: ClusterIP

port: 2020

loadBalancerClass:

loadBalancerSourceRanges: []

labels: {}

# nodePort: 30020

# clusterIP: 172.16.10.1

annotations: {}

# prometheus.io/path: "/api/v1/metrics/prometheus"

# prometheus.io/port: "2020"

# prometheus.io/scrape: "true"

serviceMonitor:

enabled: false

# namespace: monitoring

# interval: 10s

# scrapeTimeout: 10s

# jobLabel: fluentbit

# selector:

# prometheus: my-prometheus

# ## metric relabel configs to apply to samples before ingestion.

# ##

# metricRelabelings:

# - sourceLabels: [__meta_kubernetes_service_label_cluster]

# targetLabel: cluster

# regex: (.*)

# replacement: ${1}

# action: replace

# ## relabel configs to apply to samples after ingestion.

# ##

# relabelings:

# - sourceLabels: [__meta_kubernetes_pod_node_name]

# separator: ;

# regex: ^(.*)$

# targetLabel: nodename

# replacement: $1

# action: replace

# scheme: ""

# tlsConfig: {}

## Beare in mind if youn want to collec metrics from a different port

## you will need to configure the new ports on the extraPorts property.

additionalEndpoints: []

# - port: metrics

# path: /metrics

# interval: 10s

# scrapeTimeout: 10s

# scheme: ""

# tlsConfig: {}

# # metric relabel configs to apply to samples before ingestion.

# #

# metricRelabelings:

# - sourceLabels: [__meta_kubernetes_service_label_cluster]

# targetLabel: cluster

# regex: (.*)

# replacement: ${1}

# action: replace

# # relabel configs to apply to samples after ingestion.

# #

# relabelings:

# - sourceLabels: [__meta_kubernetes_pod_node_name]

# separator: ;

# regex: ^(.*)$

# targetLabel: nodename

# replacement: $1

# action: replace

prometheusRule:

enabled: false

# namespace: ""

# additionalLabels: {}

# rules:

# - alert: NoOutputBytesProcessed

# expr: rate(fluentbit_output_proc_bytes_total[5m]) == 0

# annotations:

# message: |

# Fluent Bit instance {{ $labels.instance }}'s output plugin {{ $labels.name }} has not processed any

# bytes for at least 15 minutes.

# summary: No Output Bytes Processed

# for: 15m

# labels:

# severity: critical

dashboards:

enabled: false

labelKey: grafana_dashboard

annotations: {}

namespace: ""

lifecycle: {}

# preStop:

# exec:

# command: ["/bin/sh", "-c", "sleep 20"]

livenessProbe:

httpGet:

path: /

port: http

readinessProbe:

httpGet:

path: /api/v1/health

port: http

resources: {}

# limits:

# cpu: 100m

# memory: 128Mi

# requests:

# cpu: 100m

# memory: 128Mi

## only available if kind is Deployment

ingress:

enabled: false

className: ""

annotations: {}

# kubernetes.io/ingress.class: nginx

# kubernetes.io/tls-acme: "true"

hosts: []

# - host: fluent-bit.example.tld

extraHosts: []

# - host: fluent-bit-extra.example.tld

## specify extraPort number

# port: 5170

tls: []

# - secretName: fluent-bit-example-tld

# hosts:

# - fluent-bit.example.tld

## only available if kind is Deployment

autoscaling:

vpa:

enabled: false

annotations: {}

# List of resources that the vertical pod autoscaler can control. Defaults to cpu and memory

controlledResources: []

# Define the max allowed resources for the pod

maxAllowed: {}

# cpu: 200m

# memory: 100Mi

# Define the min allowed resources for the pod

minAllowed: {}

# cpu: 200m

# memory: 100Mi

updatePolicy:

# Specifies whether recommended updates are applied when a Pod is started and whether recommended updates

# are applied during the life of a Pod. Possible values are "Off", "Initial", "Recreate", and "Auto".

updateMode: Auto

enabled: false

minReplicas: 1

maxReplicas: 3

targetCPUUtilizationPercentage: 75

# targetMemoryUtilizationPercentage: 75

## see HorizontalPodAutoscaler Walkthrough

customRules: []

# - type: Pods

# pods:

# metric:

# name: packets-per-second

# target:

# type: AverageValue

# averageValue: 1k

## see Horizontal Pod Autoscaling

behavior: {}

# scaleDown:

# policies:

# - type: Pods

# value: 4

# periodSeconds: 60

# - type: Percent

# value: 10

# periodSeconds: 60

## only available if kind is Deployment

podDisruptionBudget:

enabled: false

annotations: {}

maxUnavailable: "30%"

nodeSelector:

node-role.kubernetes.io/master: ''

tolerations:

- key: node-role.kubernetes.io/master

operator: Exists

effect: NoSchedule

affinity: {}

labels: {}

annotations: {}

podAnnotations: {}

podLabels: {}

## How long (in seconds) a pods needs to be stable before progressing the deployment

minReadySeconds:

## How long (in seconds) a pod may take to exit (useful with lifecycle hooks to ensure lb deregistration is done)

terminationGracePeriodSeconds:

priorityClassName: ""

env: []

# - name: FOO

# value: "bar"

# The envWithTpl array below has the same usage as "env", but is using the tpl function to support templatable string.

# This can be useful when you want to pass dynamic values to the Chart using the helm argument "--set <variable>=<value>"

# Chart Development Tips and Tricks

envWithTpl: []

# - name: FOO_2

# value: "{{ .Values.foo2 }}"

# foo2: bar2

envFrom: []

extraContainers: []

# - name: do-something

# image: busybox

# command: ['do', 'something']

flush: 1

metricsPort: 2020

extraPorts: []

# - port: 5170

# containerPort: 5170

# protocol: TCP

# name: tcp

# nodePort: 30517

extraVolumes: []

extraVolumeMounts: []

updateStrategy: {}

# type: RollingUpdate

# rollingUpdate:

# maxUnavailable: 1

# Make use of a pre-defined configmap instead of the one templated here

existingConfigMap: ""

networkPolicy:

enabled: false

# ingress:

# from: []

luaScripts: {}

## Configuration File - Fluent Bit: Official Manual

config:

service: |

[sERVICE]

Daemon Off

Flush {{ .Values.flush }}

Log_Level {{ .Values.logLevel }}

Parsers_File parsers.conf

Parsers_File custom_parsers.conf

HTTP_Server On

HTTP_Listen 0.0.0.0

HTTP_Port {{ .Values.metricsPort }}

Health_Check On

## Inputs - Fluent Bit: Official Manual

inputs: |

[iNPUT]

Name tail

Path /var/log/kube-apiserver/*.log

multiline.parser docker, cri

Tag audit.kube-apiserver.*

DB /tmp/kube_apiserver.db

Mem_Buf_Limit 50MB

Refresh_Interval 10

Skip_Empty_Lines On

Buffer_Chunk_Size 5M

Buffer_Max_Size 50M

Skip_Long_Lines Off

[iNPUT]

Name tail

Path /var/log/openshift-apiserver/*.log

multiline.parser docker, cri

Tag audit.openshift-apiserver.*

DB /tmp/openshift-apiserver.db

Mem_Buf_Limit 50MB

Refresh_Interval 10

Skip_Empty_Lines On

Buffer_Chunk_Size 5M

Buffer_Max_Size 50M

Skip_Long_Lines Off

[iNPUT]

Name tail

Path /var/log/oauth-apiserver/*.log

multiline.parser docker, cri

Tag audit.oauth-apiserver.*

DB /tmp/oauth-apiserver.db

Mem_Buf_Limit 50MB

Refresh_Interval 10

Skip_Empty_Lines On

Buffer_Chunk_Size 5M

Buffer_Max_Size 50M

Skip_Long_Lines Off

## Filters - Fluent Bit: Official Manual

filters: |

[FILTER]

Name kubernetes

Match kube.*

Merge_Log On

Keep_Log Off

K8S-Logging.Parser On

K8S-Logging.Exclude On

## Outputs - Fluent Bit: Official Manual

outputs: |

[OUTPUT]

Name stdout

Match *

## Upstream Servers - Fluent Bit: Official Manual

## This configuration is deprecated, please use `extraFiles` instead.

upstream: {}

## Parsers - Fluent Bit: Official Manual

customParsers: |

[PARSER]

Name docker_no_time

Format json

Time_Keep Off

Time_Key time

Time_Format %Y-%m-%dT%H:%M:%S.%L

# This allows adding more files with arbitary filenames to /fluent-bit/etc by providing key/value pairs.

# The key becomes the filename, the value becomes the file content.

extraFiles: {}

# upstream.conf: |

# [uPSTREAM]

# upstream1

# [NODE]

# name node-1

# host 127.0.0.1

# port 43000

# example.conf: |

# [OUTPUT]

# Name example

# Match foo.*

# Host bar

# The config volume is mounted by default, either to the existingConfigMap value, or the default of "fluent-bit.fullname"

volumeMounts:

- name: config

mountPath: /fluent-bit/etc/fluent-bit.conf

subPath: fluent-bit.conf

- name: config

mountPath: /fluent-bit/etc/custom_parsers.conf

subPath: custom_parsers.conf

daemonSetVolumes:

- name: varlog

hostPath:

path: /var/log

- name: varlibdockercontainers

hostPath:

path: /var/lib/docker/containers

- name: etcmachineid

hostPath:

path: /etc/machine-id

type: File

daemonSetVolumeMounts:

- name: varlog

mountPath: /var/log

- name: varlibdockercontainers

mountPath: /var/lib/docker/containers

readOnly: true

- name: etcmachineid

mountPath: /etc/machine-id

readOnly: true

args: []

command: []

# This supports either a structured array or a templatable string

initContainers: []

# Array mode

# initContainers:

# - name: do-something

# image: bitnami/kubectl:1.22

# command: ['kubectl', 'version']

# String mode

# initContainers: |-

# - name: do-something

# image: bitnami/kubectl:{{ .Capabilities.KubeVersion.Major }}.{{ .Capabilities.KubeVersion.Minor }}

# command: ['kubectl', 'version']

logLevel: info

Se desejar comparar o arquivo que está sendo criado com o arquivo oficial do Fluent Bit, você pode acessar o repositório do Fluent Bit, o arquivo yaml acima também tem a configuração para as pastas abaixo de logs do Azure Red Hat OpenShift que usam a tag [iNPUT].

/var/log/kube-apiserver
/var/log/openshift-apiserver
/var/log/oauth-apiserver

Nessa configuração acima estão também estamos usando a imagem com a tag “latest-debug”, com essa tag é possível ver os logs do Fluent Bit no console do pod após a instalação do Fluent Bit no cluster, para isso basta executar o comando abaixo:

ls /var/log/kube-apiserver

ls /var/log/openshift-apiserver

ls /var/log/oauth-apiserver

Para realizar a instalação, esteja na mesma pasta em que o arquivo values.yaml foi criado e execute o comando abaixo.

kubectl create namespace logging

helm install fluent-bit fluent/fluent-bit --namespace logging --values values.yaml

Logo após instalado, vá ao dashboard do seu cluster, selecione workloads e pods na aba lateral e selecione o project como logging, você deve ter a mesma quantidade de pods que o cluster tem de worker nodes, no meu caso são três workers nodes.

Com a configuração atual estamos somente lendo os arquivos de logs e mostrando no terminal.

Criando um Log Analytics workspace

Para enviarmos os logs para o Azure Monitor precisamos criar um Log Analytics workspace, para isso acesse siga os passos

Após a criação do Log Analytics workspace e acesse o mesmo e na menu lateral nos settings clique no Agents.

Salve o Workspace ID e o Primary Key, pois vamos usar os mesmo para a nova configuração.

Agora precisamos adicionar mais um output na configuração do ConfigMap do Fluent Bit.

Vá no ConfigMap(fluent-bit) e adicione o output abaixo no final do arquivo e clique no salvar.

## Outputs - Fluent Bit: Official Manual

[OUTPUT]
Name azure
Match *
Customer_ID ${WorkspaceId}
Shared_Key ${SharedKey}
Log_Type AuditOpenshift
Execute o comando abaixo para criar uma Secret com o WorkspaceId e SharedKey (que é o seu Primary Key). Mude o xxxx para o seus valores

kubectl create secret generic fluentbit-secret --from-literal=SharedKey="xxxx" --from-literal=WorkspaceId="xxxx" -n logging
Após criar a secret você pode verificar a mesma rodando o comando abaixo.

kubectl get secret fluentbit-secret -n logging
Agora precisamos adicionar secret no DaemonSet, para isso vá no menu lateral e selecione DaemonSets e clique no fluent-bit e selecione Enviroments
Clique no Add from ConfigMap or Secret
Adicione as environments SharedKey e WorkspaceId e no Select a resource , selecione o Secret que foi criado anteriormente fluent-bit-secret, deixe igual a imagem abaixo e clique no save.
Para que a nova configuração seja aplicada, é necessário excluir os Pods atuais; execute o comando abaixo.

kubectl delete pods -l app.kubernetes.io/instance=fluent-bit -n logging
Após deletar os pods, você pode verificar que os novos pods já estão sendo criados com a nova configuração, para isso execute o comando abaixo.

kubectl get pods -l app.kubernetes.io/instance=fluent-bit -n logging
# Utilize o nome do primeiro de pod que aparecer e execute o comando abaixo para ver os logs do pod.
kubectl logs fluent-bit-xxxx -n logging | grep "customer_id="
Vai mostrar os logs como abaixo, mostrando que o output para o Log Analytics workspace a foi enviado com sucesso.

[2023/06/06 16:37:07] [ info] [output:azure:azure.1] customer_id=247446f4-e70c-4338-87d3-ba4f902a82c9, HTTP status=200
[2023/06/06 16:37:07] [ info] [output:azure:azure.1] customer_id=247446f4-e70c-4338-87d3-ba4f902a82c9, HTTP status=200
[2023/06/06 16:37:08] [ info] [output:azure:azure.1] customer_id=247446f4-e70c-4338-87d3-ba4f902a82c9, HTTP status=200
[2023/06/06 16:37:08] [ info] [output:azure:azure.1] customer_id=247446f4-e70c-4338-87d3-ba4f902a82c9, HTTP status=200
[2023/06/06 16:37:09] [ info] [output:azure:azure.1] customer_id=247446f4-e70c-4338-87d3-ba4f902a82c9, HTTP status=200

Vizualizando os logs de auditoria no Log Analytics workspace

Entre no portal da azure, busque na barra de pesquisa do Log Analytics workspace e na lista selecione o Log Analytics workspace que foi criado nos passos anteriores.
No menu lateral selecione logs como na imagem abaixo.
Vai abrir uma tela de queries e feche a mesma.
Em tables, abra custom logs e deve ter uma tabela com no nome AuditOpenshift_CL
Vá no campo e coloque o comando abaixo e clique no Run

AuditOpenshift_CL |
take 100
Após rodar o comando, irá mostrar todos os logs de auditoria que estão sendo enviados para o Log Analytics workspace

Conclusão

Em resumo, o Fluent Bit é uma ferramenta poderosa para coletar e enviar logs para o Log Analytics Workspace da Azure. Com a configuração correta, você pode coletar logs de vários serviços e aplicativos em execução em seu cluster Kubernetes(OpenShift) e enviá-los para o Log Analytics Workspace para análise e monitoramento. Além disso, o Fluent Bit é altamente configurável e pode ser personalizado para atender às suas necessidades específicas. Esperamos que este guia tenha sido útil para você começar a usar o Fluent Bit em seu ambiente Kubernetes(OpenShift).

Referências

Quote

Sign In

Utilizando Log Analytics para monitorar logs de auditoria do Azure RedHat OpenShift

Featured Replies

Join the conversation

Account

Navigation

Search