Page Comparison

In most cases, the ingestion to Kloudfuse data plane from various telemetry agents/collectors is secure (encrypted) due to using HTTPS (TLS) which provides transport layer encryption. More on the TLS handshake conducted between the clients and the server can be found online. This documentation explains how to add authentication to the ingestion in addition to confidentiality provided by HTTPS.

Kloudfuse supports many telemetry agents (choose the steps which are relevant to the agent you are using). To enable authentication for ingestion, follow these 3 steps. For step 2 choose the section relevant to the agents being used.

Step 1. Generate AUTH_TOKEN

Generate an auth token (referred to as AUTH_TOKEN) and store this value in a safe location. You will need to use this later in more than one place.

...

AUTH_TOKEN_ENCODED=`echo -n $AUTH_TOKEN | base64`

Step 2. Configure Telemetry agents/sources

Follow instructions for the corresponding sources below.

1. Prometheus Remote Write

2. Fluent Bit

3. Fluentd

4. Filebeat

5. OLTP Collector for Metrics/Logs/Traces

6. Datadog/Kfuse agent

7. AWS CloudWatch metrics & Logs (Kinesis)

8. AWS Eventbridge Events

Prometheus Remote Write

Update prometheus remote write configuration as shown below:

    prometheus.yml:
      remote_write:
      - url: https://<customer>.kloudfuse.io/ingester/write
        authorization:
          credentials: <AUTH_TOKEN>

If you’re using prometheus operator, please refer to the configuration below

remoteWrite:
  - authorization:
      credentials:
        key: authToken
        name: kf-auth-ingest
    url: https://<customer>.kloudfuse.io/ingester/write

Fluent Bit

Update/Add the following Headers field with AUTH_TOKEN replaced with the one generated in step 1, in the HTTP plugin section of the fluent-bit configuration file as shown below:

    [OUTPUT]
        Name http
        Match <match_pattern>
        Host <kfuse_ingress_ip>
        Port 443
        TLS on
        URI /ingester/v1/fluent_bit
        Headersheader Kf-Api-Key <AUTH_TOKEN>

Using Kubernetes Secret for setting the Kf-Api-Key

1. Create a secret as following

apiVersion: v1
kind: Secret
metadata:  
  name: <<secret-name>>
type: Opaque
data:
  AUTH_KEY_ENV: AUTH_TOKEN_ENCODED

2. Update the fluent-bit helm custom-values.yaml as below

env:
- name: AUTH_KEY_ENV
  valueFrom:
      secretKeyRef:
        name: <<secret-name>>
        key: AUTH_KEY_ENV


config:
  outputs: |
    [OUTPUT]
        Name http
        Header Kf-Api-Key ${AUTH_KEY_ENV}
        Match *
        Host swapnil-dev.kloudfuse.io
        Port 443
        TLS on
        URI /ingester/v1/fluent_bit
        Format {json|json_lines|json_stream|msgpack}

Fluentd

Update/Add the fluentd output http plugin configuration to add a “headers" field as described below using the Kf-Api-Key and AUTH_TOKEN:

<match *> # Match everything
  @type http
  endpoint http://<KFUSE_INGESTER_IP>:80/ingester/v1/fluentd
  headers {"Kf-Api-Key" : "<AUTH_TOKEN>"}
  ...
</match>

Filebeat

Update/Add the filebeat configuration to include the api_key field within the output section:

output.elasticsearch: 
  hosts: ["http://<ingress-ip>:80/ingester/api/v1/filebeat"]
  api_key: "<AUTH_TOKEN>"

OLTP Collector for Metrics/Logs/Traces

Update/Add following headers section in the exporters section.

exporters:
  otlphttp:
    endpoint: https://<ingress-address>/ingester/otlp/metrics
    traces_endpoint: https://<ingress-address>/ingester/otlp/traces
    headers:
      kf-api-key: <AUTH_TOKEN>

DD/Kfuse agent

Update/Add the dd-agent configuration file to add the AUTH_TOKEN as the apiKey as shown below:

datadog:
  apiKey: <AUTH_TOKEN>
  ...
 

AWS CloudWatch metrics & Logs (Kinesis)

When configuring kinesis firehose data stream to send logs/metrics from Cloudwatch, use the AUTH_TOKEN value generated in step 1 as the access token. If the firehose data stream is already setup, then update it to use AUTH_TOKEN value as access token.

AWS Eventbridge Events

When configuring Eventbridge to ingest to Kloudfuse, use AUTH_TOKEN as the value for the Kf_Api_Key.

Step 3: Configure kfuse

Use the base64 encoded value of the AUTH_TOKEN (AUTH_TOKEN_ENCODED) and create a kubernetes secret with the name kfuse-auth-ingest:

apiVersion: v1
kind: Secret
metadata:  
  name: kfuse-auth-ingest
type: Opaque
data:
  authToken: <AUTH_TOKEN_ENCODED>

Multiple Authorization Keys

You can configure multiple authorization tokens inside the secret. These tokens can contain any string value, and can be used as a human-readable identifier to reference the auth token.

Here, line 8 specifies the second key, authkey2.

apiVersion: v1
kind: Secret
metadata:  
  name: kfuse-auth-ingest
type: Opaque
data:
  authkey1: <AUTH_TOKEN_ENCODED>

...

  authkey2: <AUTH_TOKEN_ENCODED2>

Remember to update the custom-values.yaml file to include following in the ingester config section:enable ingestion authentication:

global:
  authConfig:
    enabled: true

Configuration of Additional Labels based on Auth Token

From Kloudfuse 2.7.2 onwards, additional labels can be configured to be attached to MELT data based on the auth token used by the incoming payload.

To configure these labels, add the following in the custom-values.yaml (replace accordingly). Take note that the same keys are used in the secret and the ingester config.

ingester:
  config:
     authKeyAdditionalLabels:
        authkey1:
    authConfig:      - name: label1
            value: val1
          - name: label2
            value: val2
        authkey2:
          - name: label1
            value: val3
          - name: label4
            enabled: truevalue: val4 

Restart the ingester post the auth-token changes

kubectl -n kfuse rollout restart sts ingester