--- title: "Archive logs" description: "Forward Calico Cloud flow, DNS, audit, and L7 logs to Syslog, Splunk, or Amazon S3 to retain compliance data beyond managed retention windows." product: "Calico Cloud" version: "v23.0.1" section: "Observability" canonical_url: "https://docs.tigera.io/calico-cloud/observability/elastic/archive-storage" --- # Archive logs ## Big picture Archive Calico Cloud logs to SIEMs like Syslog, Splunk, or Amazon S3 to meet compliance storage requirements. ## Value Archiving your Calico Cloud Elasticsearch logs to storage services like Amazon S3, Syslog, or Splunk are reliable options for maintaining and consolidating your compliance data long term. ## Before you begin **Supported logs for export** - Syslog - flow, dns, idsevents, audit - Amazon S3 - l7, flow, dns, runtime, audit - Splunk - flow, audit, dns ## How to > **SECONDARY:** Because Calico Cloud and Kubernetes logs are integral to Calico Cloud diagnostics, there is no mechanism to tune down the verbosity. To manage log verbosity, filter logs using your SIEM. **Tab: Amazon S3** 1. Create an AWS bucket to store your logs. You will need the bucket name, region, key, secret key, and the path in the following steps. 2. Create a Secret in the `tigera-operator` namespace named `log-collector-s3-credentials` with the fields `key-id` and `key-secret`. Example: ```text kubectl create secret generic log-collector-s3-credentials \ --from-literal=key-id= \ --from-literal=key-secret= \ -n tigera-operator ``` 3. Update the [LogCollector](https://docs.tigera.io/calico-cloud/reference/installation/api.md#logcollector) resource named, `tigera-secure` to include an [S3 section](https://docs.tigera.io/calico-cloud/reference/installation/api.md#s3storespec) with your information noted from above. Example: ```yaml apiVersion: operator.tigera.io/v1 kind: LogCollector metadata: name: tigera-secure spec: additionalStores: s3: bucketName: bucketPath: region: ``` This can be done during installation by editing the custom-resources.yaml by applying it, or after installation by editing the resource with the command: ```bash kubectl edit logcollector tigera-secure ``` **Tab: Syslog** 1. Update the [LogCollector](https://docs.tigera.io/calico-cloud/reference/installation/api.md#logcollector) resource named `tigera-secure` to include a [Syslog section](https://docs.tigera.io/calico-cloud/reference/installation/api.md#syslogstorespec) with your syslog information. Example: ```yaml apiVersion: operator.tigera.io/v1 kind: LogCollector metadata: name: tigera-secure spec: additionalStores: syslog: # (Required) Syslog endpoint, in the format protocol://host:port endpoint: tcp://1.2.3.4:514 # (Optional) If messages are being truncated set this field packetSize: 1024 # (Required) Types of logs to forward to Syslog (must specify at least one option) logTypes: - Audit - DNS - Flows - IDSEvents ``` This can be done during installation by editing the custom-resources.yaml by applying it or after installation by editing the resource with the command: ```bash kubectl edit logcollector tigera-secure ``` 2. You can control which types of Calico Cloud log data you would like to send to syslog. The [Syslog section](https://docs.tigera.io/calico-cloud/reference/installation/api.md#syslogstorespec) contains a field called `logTypes` which allows you to list which log types you would like to include. The allowable log types are: - Audit - DNS - Flows - IDSEvents Refer to the [Syslog section](https://docs.tigera.io/calico-cloud/reference/installation/api.md#syslogstorespec) for more details on what data each log type represents. > **SECONDARY:** The log type `IDSEvents` is only supported for a cluster that has [LogStorage](https://docs.tigera.io/calico-cloud/reference/installation/api.md#logstorage) configured. It is because intrusion detection event data is pulled from the corresponding LogStorage datastore directly. The `logTypes` field is a required, which means you must specify at least one type of log to export to syslog. **TLS configuration** 3. You can enable TLS option for syslog forwarding by including the "encryption" option in the [Syslog section](https://docs.tigera.io/calico-cloud/reference/installation/api.md#syslogstorespec). ```yaml apiVersion: operator.tigera.io/v1 kind: LogCollector metadata: name: tigera-secure spec: additionalStores: syslog: # (Required) Syslog endpoint, in the format protocol://host:port endpoint: tcp://1.2.3.4:514 # (Optional) If messages are being truncated set this field packetSize: 1024 # (Optional) To Configure TLS mode encryption: TLS # (Required) Types of logs to forward to Syslog (must specify at least one option) logTypes: - Audit - DNS - Flows - IDSEvents ``` 4. Using the self-signed CA with the field name tls.crt, create a configmap in the tigera-operator namespace named, syslog-ca. Example: > **SECONDARY:** Skip this step if publicCA bundle is good enough to verify the server certificates. ```bash kubectl create configmap syslog-ca --from-file=tls.crt -n tigera-operator ``` **Tab: Splunk** **Support** In this release, only [Splunk Enterprise](https://www.splunk.com/en_us/products/splunk-enterprise.html) is supported. Calico Cloud uses Splunk's **HTTP Event Collector** to send data to Splunk server. To copy the flow, audit, and dns logs to Splunk, follow these steps: 1. Create a HTTP Event Collector token by following the steps listed in Splunk's documentation for your specific Splunk version. Here is the link to do this for [Splunk version 8.0.0](https://docs.splunk.com/Documentation/Splunk/8.0.0/Data/UsetheHTTPEventCollector). 2. Create a Secret in the `tigera-operator` namespace named `logcollector-splunk-credentials` with the field `token`. Example: ```text kubectl create secret generic logcollector-splunk-credentials \ --from-literal=token= \ -n tigera-operator ``` 3. Update the [LogCollector](https://docs.tigera.io/calico-cloud/reference/installation/api.md#logcollector) resource named `tigera-secure` to include a [Splunk section](https://docs.tigera.io/calico-cloud/reference/installation/api.md#splunkstorespec) with your Splunk information. Example: ```yaml apiVersion: operator.tigera.io/v1 kind: LogCollector metadata: name: tigera-secure spec: additionalStores: splunk: # Splunk HTTP Event Collector endpoint, in the format protocol://host:port endpoint: https://1.2.3.4:8088 ``` This can be done during installation by editing the custom-resources.yaml by applying it or after installation by editing the resource with the command: ```text kubectl edit logcollector tigera-secure ```