SSL support would be beneficial especially since grafana now supports authentication. Would you consider a use_ssl attribute that enabled SSL in the nginx conf? Alternatively, one could supply their own template with whatever config they wanted.
the reason SSL was marked as out-of-scope is the added complexity to handle it appropriately.
Let's say we take the easy path and allow one config use_ssl to enable it, we should then make sure we have a certificate/key to use: some nginx packages generate one by default (is it always the case? what about the source install?) or generate one ourself (easy to do, but goes too far for this cookbook).
So let's say we take more options: use_ssl, ssl_crt_path and ssl_key_path, then the end-user is responsible for making the certificate and key available to nginx (with appropriate right, etc.). But then we're responsible for making the SSL configuration secure. Which is something we would then have to maintain and keep up-to-date.
The recommended way to use this cookbook being to create a wrapper cookbook, it makes far more sense to handle the nginx bits in it when the config becomes more sensitive. The default cookbook allows a quick up and running nginx config for discovery/dev/testing purpose, but is not meant to replace a secured production nginx configuration.
I hope to have clarified our POV on the matter, should you have any other remarks/propositions don't hesitate.
As Jonathan explained, a production-ready SSL setup will be too specific to a given organization to create a useful generic nginx template. I found this to be the case when I began the implementation with the use-case of my organization as the sample. For example, my org uses HSTS and a relatively aggressive cipher list. Adding these to the grafana cookbook felt like scope creep for the cookbook.
I hope to write a brief blog post about how I added attributes to the template, and I'll add a link to that once it's published.