ElastAlert v0.1.29连接带OAuth2认证的Elasticsearch 2.4.4咨询

Got it, let's walk through this step by step—this exact auth pattern comes up a lot with OpenShift's aggregated logging, so I’ve got a solid approach for you. Your Elasticsearch expects three key headers on every request: Authorization: Bearer <token>, X-Proxy-Remote-User, and X-Forwarded-For. Here’s how to wire ElastAlert to send them:

1. Inject OpenShift Credentials into the ElastAlert Container #

First, we need to get the necessary auth values into the ElastAlert pod. You’ve got two options depending on which identity you want ElastAlert to use:

Option A: Use the ElastAlert Service Account (Recommended for Automation) #

OpenShift automatically mounts service account credentials into every container at /var/run/secrets/kubernetes.io/serviceaccount/. This is the most maintainable option for long-running deployments:

• The valid Bearer token lives at /var/run/secrets/kubernetes.io/serviceaccount/token (rotates automatically by OpenShift)
• The service account username follows the format: system:serviceaccount:<your-namespace>:<elastalert-sa-name> (replace placeholders with your actual namespace and service account name)

Option B: Use a Specific User Account #

If you need ElastAlert to act as a human user (like the one from oc whoami):

• Generate a long-lived token for the user with oc create token <your-username> --duration=8760h (sets a 1-year expiration)
• Store this token as an OpenSecret, then mount it into the ElastAlert pod as a file or environment variable

2. Update ElastAlert’s config.yaml #

ElastAlert v0.1.29 supports custom HTTP headers via the es_additional_headers config option. We’ll also disable SSL verification to match your curl -k example (adjust if your cert is trusted):

Use Environment Variables for Dynamic Values #

ElastAlert doesn’t directly expand shell commands in the config, so we’ll use environment variables to pass in dynamic credentials. First, add these to your OpenShift Deployment config:

• ES_AUTH_TOKEN: The Bearer token (from service account file or user secret)
• ES_REMOTE_USER: The username (service account name or oc whoami output)

Then update your config.yaml to reference these variables:

es_host: es.example.test
es_port: 443
es_use_ssl: true
es_verify_certs: false  # Matches your curl -k flag
es_additional_headers:
  Authorization: "Bearer ${ES_AUTH_TOKEN}"
  X-Proxy-Remote-User: "${ES_REMOTE_USER}"
  X-Forwarded-For: "127.0.0.1"

To populate these env vars automatically:

• For service accounts, add this to your container’s entrypoint script:

  # Populate token and service account username
  export ES_AUTH_TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
  export ES_REMOTE_USER="system:serviceaccount:$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace):elastalert-sa"
  

• For user accounts, mount your secret and set ES_AUTH_TOKEN from the secret file, then hardcode or inject ES_REMOTE_USER as your username.

3. Handle Token Expiration (Critical for Uptime) #

OpenShift service account tokens expire every 24 hours by default. To avoid ElastAlert losing connectivity:

• Add a background refresh loop to your entrypoint script to re-read the auto-rotated token file:

  # Refresh token every hour to stay ahead of expiration
  while true; do
    export ES_AUTH_TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
    sleep 3600
  done &
  

• Note: If ElastAlert doesn’t pick up env var changes automatically, you’ll need to restart it periodically or use envsubst to regenerate the config file on refresh and reload the service.

4. Test the Setup #

Verify everything works by running an ElastAlert test command inside the pod:

elastalert-test-rule --config config.yaml your-test-rule.yaml

This will attempt to query Elasticsearch with your config—you’ll see immediate feedback if authentication succeeds or fails.

内容的提问来源于stack exchange，提问作者Loïc