sensitive metadata and jinja templates

Bug #1931392 reported by Peter Surda
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released

Bug Description

The documentation doesn't explain well how to use sanitized metadata (that will show up in instance-data-sensitive.json rather than instance-data.json) with jinja templates inside user-data. As far as I can see, it doesn't work. The source code mentions two magic keys that are sanitized: "merged_cfg" and "security-credentials". Defining variables with these names inside meta-data correctly sanitizes them and only puts them inside files only readable by root, however then they don't work inside user-data as jinja templates (as "{{}}", for example), they are instead replaced by CI_MISSING_JINJA_VAR. Using differently named variables makes the template work, but they aren't sanitized in the logs/runtime files.

In what way, if any, this is supposed to work? Should I instead just chmod the relevant log/runtime files through an entry in bootcmd?

Revision history for this message
James Falcon (falcojr) wrote :

Jinja templates do not work with instance-data-sensitive.json. They only worked in instance-data.json, as explained in

Changed in cloud-init:
status: New → Triaged
importance: Undecided → Wishlist
Revision history for this message
Peter Surda (surda) wrote :

Thank you for your response. I still find both the design as well as documentation confusing. For example, the documentation says:

> Because user-data and vendor-data can contain passwords both of these files are readonly for root as well.

Ok so what's the rationale for the different handling of the sensitive variables in meta-data then?

> Any instance-data-sensitive.json variables are surfaced as dot-delimited jinja template variables because cloud-config modules are run as ‘root’ user."

I have no idea what that means. Does it explain or contradict the behaviour I'm observing?

I found by trial that the only file storing the custom meta data variables which is readable by non-root is instance-data.json, so now I chmod it at the top of in bootcmd and that solves the technical aspect of the issue for me.

I don't per se mind the behaviour, I just find the documentation confusing. If there was at least an example of how to deal with situations like mine, that would be a huge improvement.

Revision history for this message
James Falcon (falcojr) wrote :

Yes, I see what you mean. The documentation is confusing. The concept of sensitive or redacted metadata was added to accommodate the "cloud-init query" command. On a launched instance, you can run something like:

cloud-init query merged_cfg

As root, you'll see the entire config, as non-root you'll see redacted as we don't want to expose sensitive data to non-root users. This is what your second quote refers to.

Since cloud-init is run as root, I think it was an oversight that the template rendering wasn't extended to include the sensitive data when this change was made. I'll put up a PR to allow sensitive data in a jinja templated config and hopefully clarify the documentation some.

Revision history for this message
James Falcon (falcojr) wrote :
James Falcon (falcojr)
Changed in cloud-init:
status: Triaged → Fix Committed
Revision history for this message
James Falcon (falcojr) wrote : Fixed in cloud-init version 21.3.

This bug is believed to be fixed in cloud-init in version 21.3. If this is still a problem for you, please make a comment and set the state back to New

Thank you.

Changed in cloud-init:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers