Crie registos de auditoria de cópias de segurança e restauro

Esta página contém os passos para instalar e configurar os componentes necessários para criar uma cópia de segurança. Também descreve como restaurar e recuperar o acesso aos registos de auditoria históricos a partir da cópia de segurança.

Configure uma cópia de segurança num contentor remoto

Esta secção contém os passos para criar uma cópia de segurança dos registos de auditoria num contentor compatível com o S3.

Antes de começar

Antes de poder criar uma cópia de segurança dos registos de auditoria, tem de ter acesso aos seguintes recursos:

  • Um contentor do S3 remoto com um ponto final, uma chave de acesso secreta e um ID da chave de acesso.
  • Um certificado de autoridade de certificação (AC) para o sistema de armazenamento.
  • Um cluster em funcionamento.

Obtenha as credenciais para aceder ao contentor de origem

Siga estes passos para encontrar as credenciais do contentor que contém os registos de auditoria:

  1. No cluster de administrador raiz, liste os contentores no espaço de nomes do seu projeto:

    kubectl get bucket -n PROJECT_NAMESPACE

    O resultado tem de ser semelhante ao exemplo seguinte, em que os contentores de registo de auditoria mostram um nome e um ponto final:

    NAME                          BUCKET NAME                   DESCRIPTION                                                         STORAGE CLASS   FULLY-QUALIFIED-BUCKET-NAME         ENDPOINT                                       REGION   BUCKETREADY   REASON                    MESSAGE
audit-logs-loki-all           audit-logs-loki-all           Bucket for storing audit-logs-loki-all logs                         Standard        wwq2y-audit-logs-loki-all           https://appliance-objectstorage.zone1.google.gdch.test   zone1    True          BucketCreationSucceeded   Bucket successfully created.
cortex-metrics-alertmanager   cortex-metrics-alertmanager   storage bucket for cortex metrics alertmanager configuration data   Standard        wwq2y-cortex-metrics-alertmanager   https://appliance-objectstorage.zone1.google.gdch.test   zone1    True          BucketCreationSucceeded   Bucket successfully created.
cortex-metrics-blocks         cortex-metrics-blocks         storage bucket for cortex metrics data                              Standard        wwq2y-cortex-metrics-blocks         https://appliance-objectstorage.zone1.google.gdch.test   zone1    True          BucketCreationSucceeded   Bucket successfully created.
cortex-metrics-ruler          cortex-metrics-ruler          storage bucket for cortex metrics rules data                        Standard        wwq2y-cortex-metrics-ruler          https://appliance-objectstorage.zone1.google.gdch.test   zone1    True          BucketCreationSucceeded   Bucket successfully created.
ops-logs-loki-all             ops-logs-loki-all             Bucket for storing ops-logs-loki-all logs                           Standard        wwq2y-ops-logs-loki-all             https://appliance-objectstorage.zone1.google.gdch.test```

  2. Com as informações da saída obtida, defina as seguintes variáveis de ambiente para a transferência:

    SRC_BUCKET= BUCKET_NAME
SRC_ENDPOINT = ENDPOINT
SRC_PATH= FULLY_QUALIFIED_BUCKET_NAME

    Substitua o seguinte:

    • BUCKET_NAME: o nome do contentor que contém os registos de auditoria para os quais quer criar a cópia de segurança. Este valor encontra-se no campo BUCKET NAME da saída.
    • ENDPOINT: o ponto final do contentor que contém os registos de auditoria para os quais quer criar a cópia de segurança. Este valor encontra-se no campo ENDPOINT da saída.
    • FULLY_QUALIFIED_BUCKET_NAME: o nome totalmente qualificado do contentor que contém os registos de auditoria para os quais quer criar a cópia de segurança. Este valor encontra-se no campo FULLY-QUALIFIED-BUCKET-NAME da saída.

  3. Obtenha o segredo do contentor que selecionou no passo anterior:

    kubectl get secret -n PROJECT_NAMESPACE -o json| jq --arg jq_src $SRC_BUCKET '.items[].metadata|select(.annotations."object.gdc.goog/subject"==$jq_src)|.name'

    O resultado tem de ser semelhante ao seguinte exemplo, onde é apresentado o nome secreto do contentor:

    "object-storage-key-sysstd-sa-olxv4dnwrwul4bshu37ikebgovrnvl773owaw3arx225rfi56swa"

  4. Usando o nome do segredo da saída que obteve, defina a seguinte variável de ambiente:

    SRC_CREDENTIALS="PROJECT_NAMESPACE/SECRET_NAME"

    Substitua SECRET_NAME pelo nome do segredo que obteve no resultado anterior.

  5. Crie o segredo para o certificado da AC do sistema de armazenamento:

    kubectl create secret generic -n PROJECT_NAMESPACE audit-log-loki-ca \
--from-literal=ca.crt=CERTIFICATE

    Substitua CERTIFICATE pelo certificado da AC do sistema de armazenamento.

  6. Defina a seguinte variável de ambiente:

    SRC_CA_CERTIFICATE=PROJECT_NAMESPACE/audit-log-loki-ca

Obtenha as credenciais para aceder ao contentor remoto

Siga os passos abaixo para encontrar as credenciais do contentor onde quer criar a cópia de segurança:

  1. Defina as seguintes variáveis de ambiente:

    DST_ACCESS_KEY_ID= ACCESS_KEY
DST_SECRET_ACCESS_KEY= ACCESS_SECRET
DST_ENDPOINT= REMOTE_ENDPOINT
DST_PATH= REMOTE_BUCKET_NAME

    Substitua o seguinte:

    • ACCESS_KEY: a chave de acesso do contentor remoto de destino.
    • ACCESS_SECRET: o segredo de acesso do contentor remoto de destino.
    • REMOTE_ENDPOINT: o ponto final do contentor remoto de destino.
    • REMOTE_BUCKET_NAME: o nome do contentor remoto de destino.

  2. Crie um segredo para o contentor remoto:

    kubectl create secret generic -n PROJECT_NAMESPACE s3-bucket-credentials \
  --from-literal=access-key-id=$DST_ACCESS_KEY_ID \
  --from-literal=secret-access-key=$DST_SECRET_ACCESS_KEY

  3. Defina a seguinte variável de ambiente com a localização do segredo:

    DST_CREDENTIALS=PROJECT_NAMESPACE/s3-bucket-credentials

  4. Se o contentor de destino exigir a configuração de um certificado da AC, crie um segredo com o certificado da AC do contentor:

    kubectl create secret generic -n PROJECT_NAMESPACE s3-bucket-ca \
--from-literal=ca.crt=REMOTE_CERTIFICATE

    Substitua REMOTE_CERTIFICATE pelo certificado da AC do contentor remoto de destino.

  5. Defina a seguinte variável de ambiente com a localização do certificado:

    DST_CA_CERTIFICATE=PROJECT_NAMESPACE/s3-bucket-ca

Configure a transferência de registos de auditoria

Siga os passos seguintes para configurar a transferência de registos de auditoria do contentor de origem para o contentor de destino para a cópia de segurança:

  1. Crie uma conta de serviço para a tarefa de transferência do registo de auditoria. Tem de conceder acesso à conta de serviço para ler o contentor de origem e os segredos no espaço de nomes do projeto.

    kubectl apply -f - <<EOF
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: audit-log-transfer-sa
  namespace: PROJECT_NAMESPACE
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: read-secrets-role
  namespace: PROJECT_NAMESPACE
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-secrets-rolebinding
  namespace: PROJECT_NAMESPACE
subjects:
- kind: ServiceAccount
  name: audit-log-transfer-sa
  namespace: PROJECT_NAMESPACE
roleRef:
  kind: Role
  name: read-secrets-role
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: audit-log-read-bucket-role
  namespace: PROJECT_NAMESPACE
rules:
- apiGroups:
  - object.gdc.goog
  resourceNames:
  - $SRC_BUCKET # Source bucket name
  resources:
  - buckets
  verbs:
  - read-object
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: audit-log-transfer-role-binding
  namespace: PROJECT_NAMESPACE
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: audit-log-read-bucket-role
subjects:
- kind: ServiceAccount
  name: audit-log-transfer-sa
  namespace: PROJECT_NAMESPACE
---
EOF

  2. Crie uma tarefa de transferência para exportar registos para o contentor remoto:

    kubectl apply -f - <<EOF
---
apiVersion: batch/v1
kind: Job
metadata:
  name: audit-log-transfer-job
  namespace: PROJECT_NAMESPACE
spec:
  template:
    spec:
      serviceAccountName: audit-log-transfer-sa
      containers:
        - name: storage-transfer-pod
          image: gcr.io/private-cloud-staging/storage-transfer:latest
          imagePullPolicy: Always
          command:
            - /storage-transfer
          args:
            - '--src_endpoint=$SRC_ENDPOINT
            - '--dst_endpoint=$DST_ENDPOINT
            - '--src_path=\$SRC_PATH
            - '--dst_path=\$DST_PATH
            - '--src_credentials=$SRC_CREDENTIALS
            - '--dst_credentials=$DST_CREDENTIALS
            - '--dst_ca_certificate_reference=$DST_CA_CERTIFICATE # Optional. Based on destination type.
            - '--src_ca_certificate_reference=$SRC_CA_CERTIFICATE
            - '--src_type=s3'
            - '--dst_type=s3'
            - '--bandwidth_limit=100M' # Optional of the form '10K', '100M', '1G' bytes per second
      restartPolicy: OnFailure # Will restart on failure.
---
EOF

Depois de agendar a tarefa, pode monitorizar a transferência de dados indicando o nome da tarefa como audit-log-transfer-job e o espaço de nomes do projeto.

A tarefa termina quando todos os dados tiverem sido transferidos para o contentor de destino.

Restaure registos de auditoria a partir da cópia de segurança

Esta secção contém os passos para restaurar os registos de auditoria a partir da cópia de segurança.

Antes de começar

Antes de poder restaurar os registos de auditoria, tem de ter acesso aos seguintes recursos:

  • O contentor de cópias de segurança do registo de auditoria com um ponto final, uma chave de acesso secreta e um ID da chave de acesso.
  • Um certificado de autoridade de certificação (AC) para o sistema de armazenamento.
  • Um cluster em funcionamento.

Crie um contentor para restaurar registos de auditoria

Siga os passos seguintes para criar um contentor para armazenar os registos de auditoria restaurados:

  1. Crie o recurso de contentor e a conta de serviço:

    kubectl apply -f - <<EOF
---
apiVersion: object.gdc.goog/v1
kind: Bucket
metadata:
  annotations:
    object.gdc.goog/audit-logs: IO
  labels:
    logging.private.gdch.goog/loggingpipeline-name: default
  name: audit-logs-loki-restore
  namespace: PROJECT_NAMESPACE
spec:
  bucketPolicy:
    lockingPolicy:
      defaultObjectRetentionDays: 1
  description: Bucket for storing audit-logs-loki logs restore
  storageClass: Standard
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: audit-logs-loki-restore-buckets-role
  namespace: PROJECT_NAMESPACE
rules:
- apiGroups:
  - object.gdc.goog
  resourceNames:
  - audit-logs-loki-restore
  resources:
  - buckets
  verbs:
  - read-object
  - write-object
---
apiVersion: v1
automountServiceAccountToken: false
kind: ServiceAccount
metadata:
  labels:
    logging.private.gdch.goog/loggingpipeline-name: default
  name: audit-logs-loki-restore-sa
  namespace: PROJECT_NAMESPACE
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: audit-logs-loki-restore
  namespace: PROJECT_NAMESPACE
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: audit-logs-loki-restore-buckets-role
subjects:
- kind: ServiceAccount
  name: audit-logs-loki-restore-sa
  namespace: PROJECT_NAMESPACE
EOF

    O contentor e o segredo são criados.

  2. Veja o contentor criado:

    kubectl get bucket audit-logs-loki-restore -n PROJECT_NAMESPACE

    O resultado tem de ser semelhante ao exemplo seguinte. A criação do contentor pode demorar alguns minutos.

    NAME                      BUCKET NAME               DESCRIPTION                                       STORAGE CLASS   FULLY-QUALIFIED-BUCKET-NAME     ENDPOINT                                       REGION   BUCKETREADY   REASON                    MESSAGE
audit-logs-loki-restore   audit-logs-loki-restore   Bucket for storing audit-logs-loki logs restore   Standard        dzbl6-audit-logs-loki-restore   https://objectstorage.zone1.google.gdch.test   zone1    True          BucketCreationSucceeded   Bucket successfully created.

    O resultado tem de mostrar o contentor que criou. A criação do contentor pode demorar alguns minutos.

  3. Com as informações da saída obtida, defina as seguintes variáveis de ambiente:

    DST_BUCKET= RESTORE_BUCKET_NAME
DST_ENDPOINT = RESTORE_ENDPOINT
DST_PATH= RESTORE_FULLY_QUALIFIED_BUCKET_NAME

    Substitua o seguinte:

    • RESTORE_BUCKET_NAME: o nome do contentor para o restauro dos registos de auditoria. Este valor encontra-se no campo BUCKET NAME da saída.
    • RESTORE_ENDPOINT: o ponto final do contentor para o restauro dos registos de auditoria. Este valor encontra-se no campo ENDPOINT da saída.
    • RESTORE_FULLY_QUALIFIED_BUCKET_NAME: o nome totalmente qualificado do contentor para o restauro dos registos de auditoria. Este valor encontra-se no campo FULLY-QUALIFIED-BUCKET-NAME da saída.

  4. Obtenha o segredo do contentor criado:

    kubectl get secret -n PROJECT_NAMESPACE -o json| jq --arg jq_src $DST_BUCKET '.items[].metadata|select(.annotations."object.gdc.goog/subject"==$jq_src)|.name'

    O resultado tem de ser semelhante ao seguinte exemplo, onde é apresentado o nome secreto do contentor:

    "object-storage-key-sysstd-sa-olxv4dnwrwul4bshu37ikebgovrnvl773owaw3arx225rfi56swa"

  5. Usando o nome do segredo da saída que obteve, defina as seguintes variáveis de ambiente:

    DST_SECRET_NAME=RESTORE_SECRET_NAME
DST_CREDENTIALS="PROJECT_NAMESPACE/RESTORE_SECRET_NAME"

    Substitua RESTORE_SECRET_NAME pelo nome do segredo que obteve no resultado anterior.

  6. Crie o segredo para o certificado da AC do sistema de armazenamento:

    kubectl create secret generic -n PROJECT_NAMESPACE audit-log-loki-restore-ca \
--from-literal=ca.crt=CERTIFICATE

    Substitua CERTIFICATE pelo certificado da AC do sistema de armazenamento.

  7. Defina a seguinte variável de ambiente para a localização do certificado:

    DST_CA_CERTIFICATE=PROJECT_NAMESPACE/audit-log-loki-restore-ca

Obtenha as credenciais para aceder ao contentor de cópia de segurança

Siga estes passos para encontrar as credenciais do contentor que contém a cópia de segurança dos registos de auditoria:

  1. Defina as seguintes variáveis de ambiente:

    SRC_ACCESS_KEY_ID= ACCESS_KEY
SRC_SECRET_ACCESS_KEY= ACCESS_SECRET
SRC_ENDPOINT= REMOTE_ENDPOINT
SRC_PATH= REMOTE_BUCKET_NAME

    Substitua o seguinte:

    • ACCESS_KEY: a chave de acesso do contentor de cópia de segurança.
    • ACCESS_SECRET: o segredo de acesso do contentor de cópia de segurança.
    • REMOTE_ENDPOINT: o ponto final do contentor de cópia de segurança.
    • REMOTE_BUCKET_NAME: o nome do contentor de cópia de segurança.

  2. Crie um segredo para o contentor de cópia de segurança:

    kubectl create secret generic -n PROJECT_NAMESPACE s3-backup-bucket-credentials \
  --from-literal=access-key-id=$SRC_ACCESS_KEY_ID \
  --from-literal=secret-access-key=$SRC_SECRET_ACCESS_KEY

  3. Defina a seguinte variável de ambiente com a localização do segredo:

    SRC_CREDENTIALS=PROJECT_NAMESPACE/s3-backup-bucket-credentials

  4. Crie um segredo com o certificado da AC do contentor:

    kubectl create secret generic -n PROJECT_NAMESPACE s3-backup-bucket-ca \
--from-literal=ca.crt=BACKUP_CERTIFICATE

    Substitua BACKUP_CERTIFICATE pelo certificado da AC do contentor de cópia de segurança.

  5. Defina a seguinte variável de ambiente com a localização do certificado:

    SRC_CA_CERTIFICATE=PROJECT_NAMESPACE/s3-backup-bucket-ca

Configure o restauro de registos de auditoria

Siga os passos seguintes para configurar a transferência de registos de auditoria do contentor de cópia de segurança para o contentor de restauro:

  1. Crie uma conta de serviço para a tarefa de transferência do registo de auditoria. Tem de conceder acesso à conta de serviço para ler e escrever a partir do contentor e dos segredos no espaço de nomes do projeto.

    kubectl apply -f - <<EOF
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: audit-log-restore-sa
  namespace: PROJECT_NAMESPACE
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: read-secrets-role
  namespace: PROJECT_NAMESPACE
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-secrets-rolebinding-restore
  namespace: PROJECT_NAMESPACE
subjects:
- kind: ServiceAccount
  name: audit-log-restore-sa
  namespace: PROJECT_NAMESPACE
roleRef:
  kind: Role
  name: read-secrets-role
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: audit-log-restore-bucket-role
  namespace: PROJECT_NAMESPACE
rules:
- apiGroups:
  - object.gdc.goog
  resourceNames:
  - $DST_BUCKET # Source bucket name
  resources:
  - buckets
  verbs:
  - read-object
  - write-object
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: audit-log-restore-role-binding
  namespace: PROJECT_NAMESPACE
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: audit-log-restore-bucket-role
subjects:
- kind: ServiceAccount
  name: audit-log-restore-sa
  namespace: PROJECT_NAMESPACE
---
EOF

  2. Crie uma tarefa de transferência para restaurar registos do contentor de cópia de segurança remota:

    kubectl apply -f - <<EOF
---
apiVersion: batch/v1
kind: Job
metadata:
  name: audit-log-restore-job
  namespace: PROJECT_NAMESPACE
spec:
  template:
    spec:
      serviceAccountName: audit-log-restore-sa
      containers:
        - name: storage-transfer-pod
          image: gcr.io/private-cloud-staging/storage-transfer:latest
          imagePullPolicy: Always
          command:
            - /storage-transfer
          args:
            - '--src_endpoint=$SRC_ENDPOINT
            - '--dst_endpoint=$DST_ENDPOINT
            - '--src_path=\$SRC_PATH
            - '--dst_path=\$DST_PATH
            - '--src_credentials=$SRC_CREDENTIALS
            - '--dst_credentials=$DST_CREDENTIALS
            - '--dst_ca_certificate_reference=$DST_CA_CERTIFICATE
            - '--src_ca_certificate_reference=$SRC_CA_CERTIFICATE # Optional. Based on destination type
            - '--src_type=s3'
            - '--dst_type=s3'
            - '--bandwidth_limit=100M' # Optional of the form '10K', '100M', '1G' bytes per second
      restartPolicy: OnFailure # Will restart on failure.
---
EOF

Depois de agendar a tarefa, pode monitorizar a transferência de dados indicando o nome da tarefa como audit-log-restore-job e o espaço de nomes do projeto.

A tarefa termina quando todos os dados tiverem sido transferidos para o contentor de destino.

Implemente uma instância de registo de auditoria para aceder aos registos

Tem de implementar uma instância do Loki, também denominada instância do registo de auditoria, para aceder aos registos restaurados.

Para configurar a instância do registo de auditoria, use a conta de serviço audit-log-restore-sa que criou para a tarefa de restauro. Siga os passos seguintes para implementar a instância:

  1. Crie um objeto ConfigMap para a configuração da instância:

    kubectl apply -f - <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: audit-logs-loki-restore
  namespace: PROJECT_NAMESPACE
data:
  loki.yaml: |-
    auth_enabled: true
    common:
      ring:
        kvstore:
          store: inmemory
    chunk_store_config:
      max_look_back_period: 0s
    compactor:
      shared_store: s3
      working_directory: /data/loki/boltdb-shipper-compactor
      compaction_interval: 10m
      retention_enabled: true
      retention_delete_delay: 2h
      retention_delete_worker_count: 150
    ingester:
      chunk_target_size: 1572864
      chunk_encoding: snappy
      max_chunk_age: 2h
      chunk_idle_period: 90m
      chunk_retain_period: 30s
      autoforget_unhealthy: true
      lifecycler:
        ring:
          kvstore:
            store: inmemory
          replication_factor: 1
          heartbeat_timeout: 10m
      max_transfer_retries: 0
      wal:
        enabled: true
        flush_on_shutdown: true
        dir: /wal
        checkpoint_duration: 1m
        replay_memory_ceiling: 20GB
    limits_config:
      retention_period: 48h
      enforce_metric_name: false
      reject_old_samples: false
      ingestion_rate_mb: 256
      ingestion_burst_size_mb: 256
      max_streams_per_user: 20000
      max_global_streams_per_user: 20000
      per_stream_rate_limit: 256MB
      per_stream_rate_limit_burst: 256MB
      shard_streams:
        enabled: false
        desired_rate: 3MB
    schema_config:
      configs:
      - from: "2020-10-24"
        index:
          period: 24h
          prefix: index_
        object_store: s3
        schema: v11
        store: boltdb-shipper
    server:
      http_listen_port: 3100
      grpc_server_max_recv_msg_size: 104857600
      grpc_server_max_send_msg_size: 104857600
    analytics:
      reporting_enabled: false
    storage_config:
      boltdb_shipper:
        active_index_directory: /data/loki/boltdb-shipper-active
        cache_location: /data/loki/boltdb-shipper-cache
        cache_ttl: 24h
        shared_store: s3
      aws:
        endpoint: $DST_ENDPOINT
        bucketnames: $DST_PATH
        access_key_id: ${S3_ACCESS_KEY_ID}
        secret_access_key: ${S3_SECRET_ACCESS_KEY}
        s3forcepathstyle: true
EOF

  2. Implemente a instância com um serviço para aceder aos registos do contentor de restauro:

    kubectl apply -f - <<EOF
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  labels:
    app: audit-logs-loki-restore
    logging.private.gdch.goog/loggingpipeline-name: default
  name: audit-logs-loki-restore
  namespace: PROJECT_NAMESPACE
spec:
  persistentVolumeClaimRetentionPolicy:
    whenDeleted: Retain
    whenScaled: Retain
  podManagementPolicy: OrderedReady
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: audit-logs-loki-restore
  serviceName: audit-logs-loki-restore
  template:
    metadata:
      labels:
        app: audit-logs-loki-restore
        app.kubernetes.io/part-of: audit-logs-loki-restore
        egress.networking.gke.io/enabled: "true"
        istio.io/rev: default
        logging.private.gdch.goog/log-type: audit
    spec:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - preference:
              matchExpressions:
              - key: node-role.kubernetes.io/control-plane
                operator: DoesNotExist
              - key: node-role.kubernetes.io/master
                operator: DoesNotExist
            weight: 1
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - audit-logs-loki-restore
              topologyKey: kubernetes.io/hostname
            weight: 100
      containers:
      - args:
        - -config.file=/etc/loki/loki.yaml
        - -config.expand-env=true
        - -target=all
        env:
        - name: S3_ACCESS_KEY_ID
          valueFrom:
            secretKeyRef:
              key: access-key-id
              name: $DST_SECRET_NAME
              optional: false
        - name: S3_SECRET_ACCESS_KEY
          valueFrom:
              secretKeyRef:
                key: secret-access-key
                name: $DST_SECRET_NAME
                optional: false
        image: gcr.io/private-cloud-staging/loki:v2.8.4-gke.2
        imagePullPolicy: Always
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /ready
            port: http-metrics
            scheme: HTTP
          initialDelaySeconds: 330
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        name: audit-logs-loki-restore
        ports:
        - containerPort: 3100
          name: http-metrics
          protocol: TCP
        - containerPort: 7946
          name: gossip-ring
          protocol: TCP
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /ready
            port: http-metrics
            scheme: HTTP
          initialDelaySeconds: 45
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        resources:
          limits:
            ephemeral-storage: 2000Mi
            memory: 8000Mi
          requests:
            cpu: 300m
            ephemeral-storage: 2000Mi
            memory: 1000Mi
        securityContext:
          readOnlyRootFilesystem: true
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /etc/loki
          name: config
        - mountPath: /data
          name: loki-storage
        - mountPath: /tmp
          name: temp
        - mountPath: /tmp/loki/rules-temp
          name: tmprulepath
        - mountPath: /etc/ssl/certs/storage-cert.crt
          name: storage-cert
          subPath: ca.crt
        - mountPath: /wal
          name: loki-storage
      dnsPolicy: ClusterFirst
      priorityClassName: audit-logs-loki-priority
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext:
        fsGroup: 10001
        runAsGroup: 10001
        runAsUser: 10001
      serviceAccount: audit-logs-loki-restore-sa
      serviceAccountName: audit-logs-loki-restore-sa
      terminationGracePeriodSeconds: 4800
      volumes:
      - emptyDir: {}
        name: temp
      - configMap:
          defaultMode: 420
          name: audit-logs-loki-restore
        name: config
      - emptyDir: {}
        name: tmprulepath
      - name: storage-cert
        secret:
          defaultMode: 420
          secretName: web-tls
  updateStrategy:
    type: RollingUpdate
  volumeClaimTemplates:
  - apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      creationTimestamp: null
      name: loki-storage
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 50Gi
      storageClassName: standard-rwo
      volumeMode: Filesystem
---
apiVersion: v1
kind: Service
metadata:
  name: audit-logs-loki-restore
  namespace: PROJECT_NAMESPACE
spec:
  internalTrafficPolicy: Cluster
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - name: http-metrics
    port: 3100
    protocol: TCP
    targetPort: http-metrics
  selector:
    app: audit-logs-loki-restore
  sessionAffinity: None
  type: ClusterIP
---
EOF

Configure a instância de monitorização para ver registos da origem de dados

Siga os passos abaixo para configurar o Grafana, também denominado instância de monitorização, para ver os registos de auditoria restaurados da instância de registo de auditoria:

  1. Aceda ao ponto final da instância de monitorização do seu projeto.
  2. No menu de navegação da interface do utilizador (IU), clique em Administração > Origens de dados.
  3. Clique em Adicionar nova origem de dados.
  4. Na página Adicionar origem de dados, selecione Loki.
  5. Na página Definições, introduza Audit Logs - Restore como valor para o campo Nome.

  6. Na secção HTTP, introduza o seguinte valor para o campo URL:

    http://audit-logs-loki-restore.PROJECT_NAMESPACE.svc:3100

  7. Na secção Cabeçalhos HTTP personalizados, introduza os seguintes valores nos campos correspondentes:

    • Header: X-Scope-OrgID
    • Valor: infra-obs

Na figura 1, Loki é apresentado como uma opção na página Adicionar origem de dados da IU da instância de monitorização. Na figura 2, a página Definições mostra os campos que tem de preencher para configurar a origem de dados.

A opção Loki é apresentada como uma origem de dados na página Adicionar origem de dados da IU.

Figura 1. A página Adicionar origem de dados na IU da instância de monitorização.

Os campos relevantes para configurar o Loki como origem de dados são apresentados na página Definições

Figura 2. A página Definições na IU da instância de monitorização.

A opção Audit Logs - Restore está agora disponível como uma origem de dados no explorador de registos.