Support secrets for blueprints

Feature Requests
1

Seems strange that secrets cannot be used inside blueprints.
Currently (2022.11) it gives an error:

Log Details (ERROR)
Logger: homeassistant.config
Source: components/blueprint/models.py:221
First occurred: 05:40:42 (1 occurrences)
Last logged: 05:40:42

Invalid config for [automation]: Failed to load blueprint: Secrets not supported in this YAML file (See ?, line ?).
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/blueprint/models.py", line 213, in _load_blueprint
    blueprint_data = yaml.load_yaml(self.blueprint_folder / blueprint_path)
  File "/usr/src/homeassistant/homeassistant/util/yaml/loader.py", line 155, in load_yaml
    return parse_yaml(conf_file, secrets)
  File "/usr/src/homeassistant/homeassistant/util/yaml/loader.py", line 168, in parse_yaml
    return _parse_yaml(SafeLoader, content, secrets)
  File "/usr/src/homeassistant/homeassistant/util/yaml/loader.py", line 198, in _parse_yaml
    yaml.load(content, Loader=lambda stream: loader(stream, secrets))
  File "/usr/local/lib/python3.10/site-packages/yaml/__init__.py", line 81, in load
    return loader.get_single_data()
  File "/usr/local/lib/python3.10/site-packages/yaml/constructor.py", line 51, in get_single_data
    return self.construct_document(node)
  File "/usr/local/lib/python3.10/site-packages/yaml/constructor.py", line 55, in construct_document
    data = self.construct_object(node)
  File "/usr/local/lib/python3.10/site-packages/yaml/constructor.py", line 100, in construct_object
    data = constructor(self, node)
  File "/usr/src/homeassistant/homeassistant/util/yaml/loader.py", line 325, in _ordered_dict
    nodes = loader.construct_pairs(node)
  File "/usr/local/lib/python3.10/site-packages/yaml/constructor.py", line 155, in construct_pairs
    value = self.construct_object(value_node, deep=deep)
  File "/usr/local/lib/python3.10/site-packages/yaml/constructor.py", line 100, in construct_object
    data = constructor(self, node)
  File "/usr/src/homeassistant/homeassistant/util/yaml/loader.py", line 325, in _ordered_dict
    nodes = loader.construct_pairs(node)
  File "/usr/local/lib/python3.10/site-packages/yaml/constructor.py", line 155, in construct_pairs
    value = self.construct_object(value_node, deep=deep)
  File "/usr/local/lib/python3.10/site-packages/yaml/constructor.py", line 100, in construct_object
    data = constructor(self, node)
  File "/usr/src/homeassistant/homeassistant/util/yaml/loader.py", line 376, in secret_yaml
    raise HomeAssistantError("Secrets not supported in this YAML file")
homeassistant.exceptions.HomeAssistantError: Secrets not supported in this YAML file

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/automation/config.py", line 113, in _try_async_validate_config_item
    validated_config = await async_validate_config_item(hass, config, full_config)
  File "/usr/src/homeassistant/homeassistant/components/automation/config.py", line 76, in async_validate_config_item
    return await blueprints.async_inputs_from_config(config)
  File "/usr/src/homeassistant/homeassistant/components/blueprint/models.py", line 302, in async_inputs_from_config
    blueprint = await self.async_get_blueprint(bp_conf[CONF_PATH])
  File "/usr/src/homeassistant/homeassistant/components/blueprint/models.py", line 280, in async_get_blueprint
    blueprint = await self.hass.async_add_executor_job(
  File "/usr/local/lib/python3.10/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/src/homeassistant/homeassistant/components/blueprint/models.py", line 221, in _load_blueprint
    raise FailedToLoad(self.domain, blueprint_path, err) from err
homeassistant.components.blueprint.errors.FailedToLoad: Failed to load blueprint: Secrets not supported in this YAML file
2

The purpose of secrets is so you can easily share your config or put it on GitHub without accidentally sharing your passwords and PI. They’re basically a worse version of blueprint inputs because

  1. You can’t define selectors for the secrets, users have to guess what goes there or you provide separate instructions
  2. Users have to hunt through your shared config to find the secrets, they arent clearly called out like inputs are when configuring a blueprint

So why would someone need secrets in blueprints when you can already substitute out personal pieces of the config as inputs?

3

I see your point - sounds reasonable.
But I am basically using secrets as globally available values, expressions and even dicts/lists- they are available for config packages & yaml dashboards.
Blueprints are used only locally - to reduce an amount of repeating code & reduce my efforts for developing/debugging etc.
Some my blueprints could use same globally defined parts of code - as secrets, but this functionality not supported.

Assume that secrets ARE supported for blueprints.
If a user decide to share a blueprint with the Community - surely he must replace all secrets with an appropriate code.

So, the idea of sharing blueprints should not exclude the idea of supporting secrets in blueprints.

Another point is - let’s add a NEW feature like a “secret” which may be used globally too.

4

This right here is actually the problem with supporting secrets in blueprints. Most users of blueprints shared on the forum don’t even look at the yaml, the whole idea is that they can use the blueprint without knowing how it works. If there was a possibility of secrets then they would have to look at the yaml to find them and add those secrets. Would really undermine their usefulness.

However I should note that while you can’t use a secret in a blueprint you can use a secret as the value of an input. So basically instead of doing this:

blueprint:
  name: Secret test
  domain: script
mode: single
sequence:
  - service: domain.do_something
    data:
      password: !secret my_password

Do this:

blueprint:
  name: Secret test
  domain: script
  input:
    password:
      name: "Password"
      default: ""
      selector:
        text:
mode: single
sequence:
  - service: domain.do_something
    data:
      password: !input password

And then when making a script from this blueprint, use the value of the secret as the value of the input:

description: ""
use_blueprint:
  path: local/secret_test.yaml
  input:
    password: !secret my_password
5

This is absolutely same what I have to do now)))
Unfortunately, this causes some decluttering too - I need to repeat same input variable in all calls.
But anyway it is shorter than repeating the code in the blueprint itself.