Building asset definitions with headers for user agent authorization

Sensu Go
1

Hello.

The sensu asset reference details how headers can be added to the asset specification in order to provide HTTP headers such as X-Forwarded-For or Authorization. Relevant example below.

  "metadata": {
    "name": "sensu-plugins-cpu-checks",
    "namespace": "default"
  },
  "type": "Asset",
  "api_version": "core/v2",
  "spec": {
    "sha512": "f0435fd0f138fc1483aa7ca1c5262f336c3d758b862a2b646928f32dd4ee4785847c63d66886127819da036a7a85c4bc22f316dbdc61fc6641db90eb45559baa",
    "url": "https://assets.bonsai.sensu.io/24e5a5d7ff0a5e63b0a6902f1224b7d4592cbdc9/sensu-plugins-cpu-checks_4.1.0_debian_linux_amd64.tar.gz",
    "headers": {
      "Authorization": "Bearer {{ .annotations.asset_token | default \"N/A\" }}",
      "X-Forwarded-For": "client1, proxy1, proxy2"
    }

I’ve put together some logic that builds my assets for creation in sensu-backend with these needed values. The asset files are created on the filesystem are and accepted into sensu with a create command. Asking sensuctl to display information on the asset correctly returns an asset with the header information as displayed below.

{
  "metadata": {
    "name": "ruby-runtime",
    "namespace": "default"
  },
  "type": "Asset",
  "api_version": "core/v2",
  "spec": {
    "sha512": "a603f430cdf1fed5003e67579ea0e16c507316d9055a5900b48f63b3d581e01271f744aaec98dc8aacc538556fa7e0dcd703247879f40d4187b933cf836f58ed",
    "url": "https://<artifact-server>/sensu-ruby-runtime_2.1.0_ruby-2.4.4_debian_linux_amd64.tar.gz",
    "headers": {
      "Authorization": "Basic <artifact-server-user>:<artifact-server-api-key>"
    }
  }
}

When an entity attempts to run a defined check and collect this asset it fails with a 401 Unauthorized.

Screen Shot 2020-09-21 at 3.06.39 PM
Screen Shot 2020-09-21 at 3.06.39 PM1198×560 30.5 KB

I am able to retrieve assets with these credentials from the same network space with other user agents, so I know the credentials function. I have attached a debug filter to a check and been unable to produce any events that would aid in troubleshooting. Both backend and agent logs are unhelpful. I would imagine I’m creating these assets incorrectly.

1 Like
2

I thunk you misconfigured your basic authentication header. It should be someting like Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l where that last part is base64-encoded username and password pair.

More info in https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization

1 Like
3

Yes this is true. Some user agents will make only providing the username and password possible. Encoding this information certainly has an effect because my checks have gone from an HTTP 401 to an HTTP 403.

Edit: I spoke too soon regarding the switch from 401 to 403. It seems the error code is inconsistent, it’ll be a 403 one run and 401 the next.