Audit Webhook: Update Auth_token documentation

[mshanmu]

https://docs.min.io/minio/baremetal/monitoring/logging/minio-logging.html#id2

When publishing audits through webhook, the above documentation mentions

"Replace TOKEN with a JSON Web Token (JWT) to use for authenticating to the webhook endpoints. Omit for endpoints which do not require authentication."

This information is incorrect.

Try doing "mc admin config set minio audit_webhook:elastic endpoint="" auth_token="". This will never work, every time failing with 401 error.

The reason is in, https://github.com/minio/minio/blob/master/internal/logger/target/http/http.go#L89 , it sets the Authorization header without "Bearer" keyword. I think this was a oversight.

But it is a good oversight :), thereby, allows the customer to set any type of authorization, which is very much desired, like below,

$ echo -n 'user:password' | base64
dXNlcjpwYXNzd29yZA==
$
$ mc admin config set minio audit_webhook:elastic endpoint="" auth_token="Basic dXNlcjpwYXNzd29yZA=="

I confirmed that this works well.

Similarly, for JWT token, it will be like below,

$ mc admin config set minio audit_webhook:elastic endpoint="" auth_token="Bearer token"

Tried through the environment variables MINIO_AUDIT_WEBHOOK_AUTH_TOKEN_ and it did not work.

Expected Behavior

Current Behavior

Possible Solution

Steps to Reproduce (for bugs)

1. Setup an audit webhook with auth token
2. Notice it does not work

Context

Regression

Your Environment

• Version used (minio --version):
• Server setup and configuration:
• Operating System and version (uname -a):
  minio/minio:RELEASE.2021-11-03T03-36-36Z

[harshavardhana]

The reason is in, https://github.com/minio/minio/blob/master/internal/logger/target/http/http.go#L89 , it sets the Authorization header without "Bearer" keyword. I think this was a oversight.

It is not an oversight @mshanmu it is to support Splunk like endpoints so you need provide the actual mechanism as well.

I.e add Bearer <your_token>

[harshavardhana]

$ mc admin config set minio audit_webhook:elastic endpoint="" auth_token="Bearer token"

This will work as long as your token is honored at the elastic endpoint.

[mshanmu]

Right, I am asking for updating the documentation. The documentation is not correct.

[harshavardhana]

https://docs.min.io/minio/baremetal/monitoring/logging/minio-logging.html#id2

We need to update the docs @ravindk89 we should say we take "free_form" tokens to allow non-Bearer tokens presented by various HTTP endpoints such as

• Splunk HTTP event target
• Logstash Basic auth target

[ravindk89]

So specifically, MINIO_LOGGER_WEBHOOK_AUTH_TOKEN or its cmd analog audit_webhook auth_token supports specifying both Bearer tokens and plaintext (or encoded) passwords, depending on what the remote requires

• For JWT authentication, specify Bearer {TOKEN}
• For basic authentication, specify Basic {PASSWORD}

Does that sound right @harshavardhana ?

[harshavardhana]

So specifically, MINIO_LOGGER_WEBHOOK_AUTH_TOKEN or its cmd analog audit_webhook auth_token supports specifying both Bearer tokens and plaintext (or encoded) passwords, depending on what the remote requires

It supports whatever you want to - it takes an "Opaque token" so you can choose to send a string of any form that satisfies your endpoint.

[ravindk89]

I'm assuming that string just has to be prefixed by the auth mechanism in question? Not 100% familiar with webauth mechs, but I am assuming based on what you're saying we could do any HTTP Security Auth Scheme as long as the string following the mechanism adheres to the requirements for that mech

That is, I could also just as easily specify SCRAM-SHA_256 realm="realm",data="data"

Or, for that matter, digest via Digest username="Username",realm="realm",qop="auth, auth-int",algorithm="SHA-256",nonce="nonce",opaque="opaque" or whatever it is.

Let me know if I'm on the right track here.

[harshavardhana]

I'm assuming that string just has to be prefixed by the auth mechanism in question? Not 100% familiar with webauth mechs, but I am assuming based on what you're saying we could do any HTTP Security Auth Scheme as long as the string following the mechanism adheres to the requirements for that mech

That is, I could also just as easily specify SCRAM-SHA_256 realm="realm",data="data"

Or, for that matter, digest via Digest username="Username",realm="realm",qop="auth, auth-int",algorithm="SHA-256",nonce="nonce",opaque="opaque" or whatever it is.

@ravindk89 yes this is the correct understanding.

[feorlen]

Note: the doc mentioned has moved here: Publish Audit Logs to HTTP Webhook