Trying to understand secrets.yaml

Configuration
1

Gone through docs, but want to make sure I get this. If in my configuration.yaml, if I have say something like for a Ring doorbell like:

# Ring
ring:
  username: [email protected]
  password: apassword

What is the best way to have this in a secrets.yaml and the reference? And then also, how is the secrets.yaml secure?

I did read this, but not sure I am understanding how the secrets.yaml is kept secure and all.

2

Have a meaningful reference, like this

# Ring
ring:
  username: !secret ring_usr
  password: !secret ring_pwd

Then in your secrets.yaml:

ring_usr: [email protected]
ring_pwd: apassword

It is only as secure as access to your config folder. Use a SAMBA password, use SSH key/password.

1 Like
3

Additionally, is there some special character format for passwords? I can have “YOUR_PASSWORD” in my secrets.yaml, but not what with alphanumeric and special characters as it adds an error on config check.

4

Nope. You should be able to use any string.

5

Sorry for necroposting but I think the last question is very relevant but not totally addressed.

If “secret.yaml is only as secure as access to your config folder”, it seems to me that anyone who has access to configuration.yaml will also be able to access secret.yaml.

Since there is no mention of crypting secret.yaml, how is that any more secure than using a plain configuration.yaml?

6

Correct.

It allows for sharing and backup of configuration files on github (the secret file is not uploaded). It is also convenient when sharing configurations on this forum as there is no need to obscure anything.

2 Likes
7

Just to add to what Tom said.

With different notifications in locations all over your configuration (and similar) it also allows the actual strings used to be kept only in one place.
So this is both tidy and convenient.
Your usage (using as Tom’s example : -

from above) makes it really obvious what it contains. Rather than having to see
username: Gh467YYyttr
You see something that makes sense
If any of my services requires that I change my key/username (can’t think why but it may happen) then I know where and just do it in one place
Using username: !secret ring_usr (as an example) is also a LOT shorter than some of my keys (duckdns, pushbullet, telegram, z_wave, metoffice etc. )
They are not hashed when stored in secrets but that allows you to manually edit them, copy them etc. In theory You could hash them when storing from (say) the front end but I think you’d lose more than you’d gain.
Remember, if someone has malicious intent with access to your config, you have a lot more to worry about than just a few passwords.

2 Likes
8

Thanks for your insight @tom_l and @Mutt

I totally agree that this is convenient.

However, I (along with OP I’d think) refer to https://www.home-assistant.io/docs/configuration/securing/ which claims that this is a “must do” for security reason, which I find misleading.

I did it anyway because it is indeed nice and tidy :slight_smile:

9

Dan, You wouldn’t believe the number of times we have people post parts of their configuration because they have a problem with something. And include a portion with ‘compromising’ information.
Using ‘secrets’ ‘should’ reduce this greatly

We also get people who redact internal IP addresses, so inherently their understanding of what should be private and what can be globally visible (without affecting security) is a bit skewed.

1 Like
10

@tom_l hi there, sorry to open an old topic like this, but can we use !secret xxx for in-line password/secret? something like below:

mysql://user:password@SERVER_IP/DB_NAME?charset=utf8mb4

Thanks

11

Make the whole URL a secret. You can’t piece meal secrets together.

4 Likes
12

oh yeah, should’ve thought that lol. thanks