Loki sink labels and dangerously_allow_unconfined_template_resolution after Vector 0.57

[Xyaren]

Question

Hi Vector team,

I have a question regarding the new template confinement behavior introduced in Vector 0.57.

I am using the Loki sink with labels like:

labels:
  host: "{{ .host }}"
  service_name: "{{ .service_name }}"
  level: "{{ .level }}"

After upgrading to 0.57, validation fails with:

Sink "loki": template references event fields ([".level"]) but has no literal string prefix to derive a confinement base from. Add a static prefix to your template, or set dangerously_allow_unconfined_template_resolution: true to opt out.

I understand the reasoning behind template confinement for cases where templates control things like paths, URLs, object keys, topics, etc.

However, for Loki labels this creates a problem: adding a literal prefix changes the actual label value and therefore changes the Loki stream identity.

For example:

Before:

{host="lx0001", level="info"}

With the suggested workaround:

host: "host={{ .host }}"

becomes:

{host="host=lx0001", level="level=info"}

This breaks existing LogQL queries, dashboards, and alerts because the label schema has changed.

Is there currently a recommended way to keep dynamic Loki label values unchanged while satisfying the confinement rules?

Possible solutions I can think of:

• A non-template field reference syntax for Loki labels (if feasible), e.g. directly mapping event fields.
• Treating Loki labels differently from routing/resource templates since they are metadata dimensions rather than destinations.
• Allowing a confinement prefix that is not included in the final rendered value.
• Any other migration pattern I may have missed.

For now, the only backwards-compatible option seems to be:

dangerously_allow_unconfined_template_resolution: true

but I wanted to confirm whether this is the intended approach for Loki labels or whether a better migration path exists.

Thanks!

Vector Config

# Loki sink to send logs
sinks:
  loki:
    # Sink ID and type
    inputs:
      - validate_before_sink
    type: loki

    # Loki endpoint configuration
    endpoint: http://10.86.255.3:3100
    healthcheck:
      enabled: false

    remove_label_fields: true
    # Labels to attach to logs
    labels:
      host: "{{ .host }}"  # Attach the host as a label
      service_name: "{{ .service_name }}"  # Attach the journald unit as a label
      #severity: "{{ severity }}"  # Attach the transformed severity as a label
      level: "{{ .level }}"  # Attach the transformed severity as a label

    # Encoding options for Loki
    encoding:
      timestamp_format: "rfc3339"  # Format for timestamps
      codec: json  # Logs are sent as JSON

    compression: snappy

    dangerously_allow_unconfined_template_resolution: true #https://vector.dev/highlights/2026-07-14-0-57-0-upgrade-guide/

Vector Logs

2026-07-19T11:45:12.357778Z  WARN sink{component_kind="sink" component_id=loki component_type=loki}: vector::template: SECURITY: component has `dangerously_allow_unconfined_template_resolution` enabled — template is NOT confined. A log producer that controls any field used in the template can write to arbitrary keys. component_kind="sink" component_type="loki" field="labels"

[thomasqueirozb]

adding a literal prefix changes the actual label value

Yes that is correct. The idea behind this new mechanism is that by gating your level template by using something like: level: lvl-{{ level }}, there is no way that the whole field can be overwritten, only something after lvl- - and not alter level completely. This was done to prevent data coming in from potentially untrusted sources from completely altering a field.

For now, the only backwards-compatible option seems to be:

dangerously_allow_unconfined_template_resolution: true

but I wanted to confirm whether this is the intended approach for Loki labels or whether a better migration path exists.

Our recommendation is to prefix templates. If you cannot add a prefix, and if you verify that .level/.service_name/.host are not able to be changed by data coming in from a source, transform or any other configuration, you can enable dangerously_allow_unconfined_template_resolution: true.

Currently all templates used in sinks adhere by template confinement. If you think that some of these fields should be an exception to this rule please open an issue. We may consider dropping dangerously_allow_unconfined_template_resolution for certain fields in the future.

Also see: #25907 (comment)

[Xyaren]

I totally undestand that for fields like bucket names or file paths, but for labels this does not make sense for me.