Audit-Logs für Sicherung und Wiederherstellung erstellen

Auf dieser Seite finden Sie die Schritte zum Installieren und Konfigurieren der erforderlichen Komponenten zum Erstellen einer Sicherung. Außerdem wird beschrieben, wie Sie den Zugriff auf alte Audit-Logs aus der Sicherung wiederherstellen und wiedererlangen.

Hinweis: Ersetzen Sie PROJECT_NAMESPACE in diesem Dokument durch Ihren Projekt-Namespace.

Back-up in einem Remote-Bucket einrichten

In diesem Abschnitt wird beschrieben, wie Sie ein Backup für Audit-Logs in einem S3-kompatiblen Bucket erstellen.

Hinweise

Bevor Sie eine Sicherung Ihrer Audit-Logs erstellen können, benötigen Sie Zugriff auf die folgenden Ressourcen:

• Ein Remote-S3-Bucket mit einem Endpunkt, einem geheimen Zugriffsschlüssel und einer Zugriffsschlüssel-ID.
• Ein Zertifikat der Zertifizierungsstelle (CA) für das Speichersystem.
• Ein funktionierender Cluster.

Anmeldedaten für den Zugriff auf den Quell-Bucket abrufen

Führen Sie die folgenden Schritte aus, um die Anmeldedaten des Buckets zu finden, der die Audit-Logs enthält:

1. Listen Sie im Stamm-Administratorcluster die Buckets in Ihrem Projekt-Namespace auf:

   kubectl get bucket -n PROJECT_NAMESPACE
   

   Die Ausgabe muss wie im folgenden Beispiel aussehen, in dem für die Audit-Logging-Buckets ein Name und ein Endpunkt angezeigt werden:

   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. Legen Sie anhand der Informationen aus der Ausgabe die folgenden Umgebungsvariablen für die Übertragung fest:

   SRC_BUCKET= BUCKET_NAME
   SRC_ENDPOINT = ENDPOINT
   SRC_PATH= FULLY_QUALIFIED_BUCKET_NAME
   

   Ersetzen Sie Folgendes:

   • BUCKET_NAME: Der Name des Buckets, der die Audit-Logs enthält, für die Sie die Sicherung erstellen möchten. Dieser Wert befindet sich im Feld BUCKET NAME der Ausgabe.
   • ENDPOINT: Der Endpunkt des Buckets, der die Audit-Logs enthält, für die Sie die Sicherung erstellen möchten. Dieser Wert befindet sich im Feld ENDPOINT der Ausgabe.
   • FULLY_QUALIFIED_BUCKET_NAME: Der vollständig qualifizierte Name des Buckets, der die Audit-Logs enthält, für die Sie die Sicherung erstellen möchten. Dieser Wert befindet sich im Feld FULLY-QUALIFIED-BUCKET-NAME der Ausgabe.

3. Rufen Sie das Secret für den Bucket ab, den Sie im vorherigen Schritt ausgewählt haben:

   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'
   

   Die Ausgabe muss wie im folgenden Beispiel aussehen, in dem der Secret-Name des Buckets angezeigt wird:

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

4. Legen Sie mit dem Secret-Namen aus der Ausgabe die folgende Umgebungsvariable fest:

   SRC_CREDENTIALS="PROJECT_NAMESPACE/SECRET_NAME"
   

   Ersetzen Sie SECRET_NAME durch den Secret-Namen, den Sie in der vorherigen Ausgabe erhalten haben.

5. Erstellen Sie das Secret für das CA-Zertifikat des Speichersystems:

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

   Ersetzen Sie CERTIFICATE durch das CA-Zertifikat des Speichersystems.

6. Legen Sie die folgende Umgebungsvariable fest:

   SRC_CA_CERTIFICATE=PROJECT_NAMESPACE/audit-log-loki-ca
   

Anmeldedaten für den Zugriff auf den Remote-Bucket abrufen

Führen Sie die folgenden Schritte aus, um die Anmeldedaten des Buckets zu finden, in dem Sie die Sicherung erstellen möchten:

1. Legen Sie die folgenden Umgebungsvariablen fest:

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

   Ersetzen Sie Folgendes:

   • ACCESS_KEY: Der Zugriffsschlüssel des Remote-Ziel-Buckets.
   • ACCESS_SECRET: das Zugriffs-Secret des Remote-Ziel-Buckets.
   • REMOTE_ENDPOINT: der Endpunkt des Remote-Ziel-Buckets.
   • REMOTE_BUCKET_NAME: der Name des Remote-Ziel-Buckets.

2. Erstellen Sie ein Secret für den Remote-Bucket:

   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. Legen Sie die folgende Umgebungsvariable mit dem Speicherort des Secrets fest:

   DST_CREDENTIALS=PROJECT_NAMESPACE/s3-bucket-credentials
   

4. Wenn für den Ziel-Bucket ein CA-Zertifikat eingerichtet werden muss, erstellen Sie ein Secret mit dem CA-Zertifikat des Buckets:

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

   Ersetzen Sie REMOTE_CERTIFICATE durch das CA-Zertifikat des Ziel-Remote-Buckets.

5. Legen Sie die folgende Umgebungsvariable mit dem Speicherort des Zertifikats fest:

   DST_CA_CERTIFICATE=PROJECT_NAMESPACE/s3-bucket-ca
   

Übertragung von Audit-Logs einrichten

Führen Sie die folgenden Schritte aus, um die Übertragung von Audit-Logs vom Quell-Bucket zum Ziel-Bucket für die Sicherung zu konfigurieren:

1. Erstellen Sie ein Dienstkonto für den Übertragungsjob für Audit-Logs. Sie müssen dem Dienstkonto Zugriff gewähren, damit es den Quell-Bucket und die Secrets im Projekt-Namespace lesen kann.

   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. Erstellen Sie einen Übertragungsjob, um Protokolle in den Remote-Bucket zu exportieren:

   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
   

Nachdem Sie den Job geplant haben, können Sie den Datenübertragungsstatus überwachen, indem Sie den Jobnamen als audit-log-transfer-job und Ihren Projektnamespace angeben.

Der Job wird beendet, wenn alle Daten in den Ziel-Bucket übertragen wurden.

Audit-Logs aus der Sicherung wiederherstellen

Dieser Abschnitt enthält die Schritte zum Wiederherstellen von Audit-Logs aus der Sicherung.

Hinweise

Bevor Sie Ihre Audit-Logs wiederherstellen können, benötigen Sie Zugriff auf die folgenden Ressourcen:

• Der Bucket für die Sicherung von Audit-Logs mit einem Endpunkt, einem geheimen Zugriffsschlüssel und einer Zugriffsschlüssel-ID.
• Ein Zertifikat der Zertifizierungsstelle (CA) für das Speichersystem.
• Ein funktionierender Cluster.

Bucket zum Wiederherstellen von Audit-Logs erstellen

Führen Sie die folgenden Schritte aus, um einen Bucket zum Speichern der wiederhergestellten Audit-Logs zu erstellen:

1. Erstellen Sie die Bucket-Ressource und das Dienstkonto:

   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
   

   Der Bucket und das Secret werden erstellt.

2. Erstellten Bucket ansehen:

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

   Die Ausgabe muss wie im folgenden Beispiel aussehen. Die Erstellung des Buckets kann einige Minuten dauern.

   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.
   

   In der Ausgabe muss der von Ihnen erstellte Bucket angezeigt werden. Die Erstellung des Buckets kann einige Minuten dauern.

3. Legen Sie anhand der Informationen aus der Ausgabe die folgenden Umgebungsvariablen fest:

   DST_BUCKET= RESTORE_BUCKET_NAME
   DST_ENDPOINT = RESTORE_ENDPOINT
   DST_PATH= RESTORE_FULLY_QUALIFIED_BUCKET_NAME
   

   Ersetzen Sie Folgendes:

   • RESTORE_BUCKET_NAME: Der Name des Buckets für die Wiederherstellung von Audit-Logs. Dieser Wert befindet sich im Feld BUCKET NAME der Ausgabe.
   • RESTORE_ENDPOINT: Der Endpunkt des Buckets für die Wiederherstellung von Audit-Logs. Dieser Wert befindet sich im Feld ENDPOINT der Ausgabe.
   • RESTORE_FULLY_QUALIFIED_BUCKET_NAME: Der vollständig qualifizierte Name des Buckets für die Wiederherstellung von Audit-Logs. Dieser Wert befindet sich im Feld FULLY-QUALIFIED-BUCKET-NAME der Ausgabe.

4. Rufen Sie das Secret des erstellten Buckets ab:

   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'
   

   Die Ausgabe muss wie im folgenden Beispiel aussehen, in dem der Secret-Name des Buckets angezeigt wird:

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

5. Legen Sie mit dem Secret-Namen aus der Ausgabe die folgenden Umgebungsvariablen fest:

   DST_SECRET_NAME=RESTORE_SECRET_NAME
   DST_CREDENTIALS="PROJECT_NAMESPACE/RESTORE_SECRET_NAME"
   

   Ersetzen Sie RESTORE_SECRET_NAME durch den Secret-Namen, den Sie in der vorherigen Ausgabe erhalten haben.

6. Erstellen Sie das Secret für das CA-Zertifikat des Speichersystems:

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

   Ersetzen Sie CERTIFICATE durch das CA-Zertifikat des Speichersystems.

7. Legen Sie die folgende Umgebungsvariable für den Speicherort des Zertifikats fest:

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

Anmeldedaten für den Zugriff auf den Sicherungs-Bucket abrufen

Führen Sie die folgenden Schritte aus, um die Anmeldedaten des Buckets zu finden, der die Sicherung der Audit-Logs enthält:

1. Legen Sie die folgenden Umgebungsvariablen fest:

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

   Ersetzen Sie Folgendes:

   • ACCESS_KEY: Der Zugriffsschlüssel des Sicherungs-Buckets.
   • ACCESS_SECRET: Das Zugriffs-Secret des Sicherungs-Buckets.
   • REMOTE_ENDPOINT: der Endpunkt des Sicherungs-Buckets.
   • REMOTE_BUCKET_NAME: der Name des Sicherungs-Buckets.

2. Erstellen Sie ein Secret für den Sicherungs-Bucket:

   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. Legen Sie die folgende Umgebungsvariable mit dem Speicherort des Secrets fest:

   SRC_CREDENTIALS=PROJECT_NAMESPACE/s3-backup-bucket-credentials
   

4. Erstellen Sie ein Secret mit dem CA-Zertifikat des Buckets:

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

   Ersetzen Sie BACKUP_CERTIFICATE durch das CA-Zertifikat des Sicherungs-Buckets.

5. Legen Sie die folgende Umgebungsvariable mit dem Speicherort des Zertifikats fest:

   SRC_CA_CERTIFICATE=PROJECT_NAMESPACE/s3-backup-bucket-ca
   

Wiederherstellung von Audit-Logs einrichten

Führen Sie die folgenden Schritte aus, um die Übertragung von Audit-Logs aus dem Sicherungs-Bucket in den Wiederherstellungs-Bucket zu konfigurieren:

1. Erstellen Sie ein Dienstkonto für den Übertragungsjob für Audit-Logs. Sie müssen dem Dienstkonto Zugriff zum Lesen und Schreiben aus dem Bucket und den Secrets im Projekt-Namespace gewähren.

   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. Erstellen Sie einen Übertragungsjob, um Logs aus dem Remote-Sicherungs-Bucket wiederherzustellen:

   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
   

Nachdem Sie den Job geplant haben, können Sie den Datenübertragungsstatus überwachen, indem Sie den Jobnamen als audit-log-restore-job und Ihren Projektnamespace angeben.

Der Job wird beendet, wenn alle Daten in den Ziel-Bucket übertragen wurden.

Audit-Log-Instanz bereitstellen, um auf die Logs zuzugreifen

Sie müssen eine Loki-Instanz, auch Audit-Log-Instanz genannt, bereitstellen, um auf die wiederhergestellten Logs zuzugreifen.

Verwenden Sie zum Einrichten der Audit-Log-Instanz das Dienstkonto audit-log-restore-sa, das Sie für den Wiederherstellungsjob erstellt haben. Führen Sie die folgenden Schritte aus, um die Instanz bereitzustellen:

1. Erstellen Sie ein ConfigMap-Objekt für die Konfiguration der Instanz:

   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. Stellen Sie die Instanz mit einem Dienst für den Zugriff auf Protokolle aus dem Wiederherstellungs-Bucket bereit:

   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
   

Monitoring-Instanz konfigurieren, um Logs aus der Datenquelle anzusehen

Hinweis :Das System kann die Konfiguration der Audit-Log-Instanz als Datenquelle zurücksetzen.

Führen Sie die folgenden Schritte aus, um Grafana (auch Monitoring-Instanz genannt) so zu konfigurieren, dass die wiederhergestellten Audit-Logs aus der Audit-Log-Instanz angezeigt werden:

1. Rufen Sie den Endpunkt der Monitoring-Instanz Ihres Projekts auf.
2. Klicken Sie im Navigationsmenü der Benutzeroberfläche auf Verwaltung > Datenquellen.
3. Klicken Sie auf  Neue Datenquelle hinzufügen.
4. Wählen Sie auf der Seite Datenquelle hinzufügen die Option Loki aus.
5. Geben Sie auf der Seite Einstellungen den Wert Audit Logs - Restore für das Feld Name ein.

6. Geben Sie im Abschnitt HTTP den folgenden Wert für das Feld URL ein:

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

7. Geben Sie im Abschnitt Benutzerdefinierte HTTP-Header die folgenden Werte in die entsprechenden Felder ein:

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

In Abbildung 1 wird Loki als Option auf der Seite Datenquelle hinzufügen der Monitoring-Instanz-UI angezeigt. In Abbildung 2 sehen Sie die Felder, die Sie auf der Seite Einstellungen ausfüllen müssen, um die Datenquelle einzurichten.

Abbildung 1. Die Seite Datenquelle hinzufügen in der Benutzeroberfläche der Monitoring-Instanz.

Abbildung 2. Die Seite Einstellungen in der Benutzeroberfläche der Monitoring-Instanz.

Die Option Audit Logs - Restore ist jetzt als Datenquelle im Log-Explorer verfügbar.