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

by | Sep 5, 2023 | Technology | 0 comments

This article is contributed. See the original author and article here.

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



 


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 Connect238048625-6f564954-2705-49c7-be99-8a3c8035037f.png

  • 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 https://fluent.github.io/helm-charts

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: https://kubernetes.io/docs/concepts/policy/pod-security-policy/

# from Kubernetes 1.25, PSP is deprecated

# See: https://kubernetes.io/blog/2022/08/23/kubernetes-v1-25-release/#pod-security-changes

# 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 https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics

  customRules: []

#     – type: Pods

#       pods:

#         metric:

#           name: packets-per-second

#         target:

#           type: AverageValue

#           averageValue: 1k

    ## see https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-configurable-scaling-behavior

  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 =”

# https://helm.sh/docs/howto/charts_tips_and_tricks/#using-the-tpl-function

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: {}


## https://docs.fluentbit.io/manual/administration/configuring-fluent-bit/classic-mode/configuration-file

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


  ## https://docs.fluentbit.io/manual/pipeline/inputs

  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


  ## https://docs.fluentbit.io/manual/pipeline/filters

  filters: |

    [FILTER]

        Name kubernetes

        Match kube.*

        Merge_Log On

        Keep_Log Off

        K8S-Logging.Parser On

        K8S-Logging.Exclude On


  ## https://docs.fluentbit.io/manual/pipeline/outputs

  outputs: |

    [OUTPUT]

        Name stdout

        Match *


  ## https://docs.fluentbit.io/manual/administration/configuring-fluent-bit/classic-mode/upstream-servers

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

  upstream: {}


  ## https://docs.fluentbit.io/manual/pipeline/parsers

  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.


1.png

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


9.png

 


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.


2.png

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.


      ## https://docs.fluentbit.io/manual/pipeline/outputs
    

        [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




  • 0.png




  • Clique no Add from ConfigMap or Secret3.png




  • 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.4.png




  • 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




  1. 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.




  2. No menu lateral selecione logs como na imagem abaixo.







  3. Vai abrir uma tela de queries e feche a mesma.




  4. Em tables, abra custom logs e deve ter uma tabela com no nome AuditOpenshift_CL




  5. Vá no campo e coloque o comando abaixo e clique no Run


    AuditOpenshift_CL |
    
take 100



  6. Após rodar o comando, irá mostrar todos os logs de auditoria que estão sendo enviados para o Log Analytics workspace6.png




 


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


 


Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.

Submit a Comment