Nested secrets

Feature Requests
1

Hi guys,

I’m wondering if it’s possible to have a nested secrets structure? I quickly tried and it seems HA couldn’t handle it.
If not, consider this a feature request :smiley:

What I had in mind is something like the variables in flexget (https://flexget.com/Plugins/variables)
Basically what it boils down to, is having the following structure in the secrets:

http:
  password: blabla
  ssl:
    cert: path/to/cert
    key: path/to/key

Which can then be used like:

http:
  api_password: !secret http.password
  ssl_cert: !secret http.ssl.cert

This brings off course a little extra typing work, but in my opinion, it is a lot easier this way, to keep track off all the secrets, and nicely bundle them together in a structured way. Those not wanting to use this feature, can still define them as flat keys and they would still work.

2

From what I can see you’ve taken what is currently 3 easy lines in the secrets file, and turned them into 5 not so easy lines with the added complication of the references being more obscure.

Perhaps I missed something but I can’t see any advantage to this over the current approach.

2 Likes
3

Well, at first I had my secrets all named with either all lowercase or camelcase, which was getting hard to read. Even tried using underscores but still wasn’t to my liking.
I am now using the same structure with the dot in the middle, but got them named exactly the same in my secrets file. This way it more resembles closely a JSON structure, which makes a lot of sense for me, seeing as you can more easily group related stuff together.

What you mentioned is true, it does add complexity to the structure, for now the flat dot notations I use are sufficient enough for me

4

I second this as well. I’m used to working with YAML variable files that allow nesting and was surprised that HA could not parse as I was cleaning up my config repo.

5

I agree. When you are used to working with YAML files, this is the kind of behavior you expected.

6

Would be awesome as this is the expected behavior when working with YAML files

7

May be I am missing something - but secrets can have a complex structure.

some_secret:
  min: 0
  max: 100
  step: 1
  mode: slider

input_number:
  some_number: !secret some_secret

A stupid example but it demonstrates the idea.

8

I also don’t grok.
I only have one secrets file. The secrets file in ESPHome points to the main secrets file:

# U:\esphome\secrets.yaml
# Use the secrets file in config
!include ../secrets.yaml

I really don’t see any advantage to anything more complex than the current key:secret structure.