In the previous post, we discussed how to write your own custom Grafana datasource plugin.

We recently upgraded our backend to move from a username/password to certificate mode. This necessitated updating the datasource plugin to be able to make a request to the backend with a certificate.

The documentation, as per the course with Grafana, was scattered and not intuitive. Ironically, it was this forum question, that asked about key formatting in yaml provisioning files that gave the clue as the cleanest/most effective way to get this done.

In short, rather than having a user put absolute paths in your UI form fields and having the plugin do the conversion somehow in the backend, you can write a "provisioning" file that will configure your plugin when Grafana starts up.

This yaml file is placed in GRAFANA_DIR/conf/provisioning/datasources or the equivalent for your installation:

# # config file version
apiVersion: 1

# # list of datasources to insert/update depending
# # on what's available in the database
datasources:
#   # <string, required> name of the datasource. Required
 - name: Datasource Name
#   # <string, required> datasource type. Required
   type: idFromPluginJsonFile 
#   # <string, required> access mode. direct or proxy. Required
   access: proxy
#   # <int> org id. will default to orgId 1 if not specified
#   orgId: 1
#   # <bool> mark as default datasource. Max one per org
   isDefault: false
#   # <map> fields that will be converted to json and stored in json_data
   jsonData:
      url: https://localhost:8080
      tlsAuth: true
      tlsAuthWithCACert: true
#   # <string> json object of data that will be encrypted.
#   certs can be yaml formatted with "| actual string" OR "Base64PEM"
   secureJsonData:
     tlsCACert: |
        -----BEGIN CERTIFICATE-----
        ...
        -----END CERTIFICATE-----
     tlsClientCert: |
        -----BEGIN CERTIFICATE-----
        ...
        -----END CERTIFICATE-----
     tlsClientKey: |
        -----BEGIN PRIVATE KEY-----
        ...
        -----END PRIVATE KEY-----
#   # <bool> allow users to edit datasources from the UI.
   editable: false

The tls* configuration items in secureJsonData are magically handed off to the go backend when it needs to make network requests. The documentation seems to suggest this is only applicable for certain datasource plugins, but that doesn't seem to be the case; it applies equally for any datasource needing a certificate/TLS connection.

Why this isn't in the authentication section is beyond me.