Use instance-data-sensitive.json in jinja templates (SC-117)

[TheRealFalcon]

Proposed Commit Message

Use instance-data-sensitive.json in jinja templates

instance-data.json redacts sensitive data for non-root users. Since user
data is consumed as root, we should be consuming the non-redacted data
instead.

LP: #1931392

Additional Context

https://bugs.launchpad.net/cloud-init/+bug/1931392

Test Steps

Run unit tests

Checklist:

• My code follows the process laid out in the documentation
• I have updated or added any unit tests accordingly
• I have updated or added any documentation accordingly

[blackboxsw]

+1 minor doc-supplement to add more context about behavior if helpful. Take what you will.

[blackboxsw]

+1 updating docs here!

Here's another supplement that hopefully we add a bit of clarity for the original bug-filer as well

diff --git a/doc/rtd/topics/instancedata.rst b/doc/rtd/topics/instancedata.rst
index 2edf8d2a..c0a61f24 100644
--- a/doc/rtd/topics/instancedata.rst
+++ b/doc/rtd/topics/instancedata.rst
@@ -564,9 +564,40 @@ Below are some examples of providing these types of user-data:
    {%- endif %}
    ...
 
+
+One way to easily explore what Jinja variables are available on your machine
+is to use the cloud-init query --format (-f) commandline option which will
+render any Jinja syntax you use. Warnings or exceptions will be raised on
+invalid instance-data keys, paths or invalid syntax.
+
+.. code-block:: shell-session
+ # List all instance-data keys and values as root user
+ % sudo cloud-init query --all
+ {...}
+
+ # Introspect available keys on an object in jinja
+ % cloud-init query -f "{{ds.keys()}}"
+ dict_keys(['meta_data', '_doc'])
+
+ # Test your Jinja rendering syntax on the command-line directly
+
+ # Failure to reference valid top-level instance-data key
+ % cloud-init query -f "{{invalid.instance-data.key}}"
+ WARNING: Ignoring jinja template for query commandline: 'invalid' is undefined
+
+ # Failure to reference valid dot-delimited key path on a known top-level key
+ % cloud-init query -f "{{v1.not_here}}"
+ WARNING: Could not render jinja template variables in file 'query commandline': 'not_here'
+ CI_MISSING_JINJA_VAR/not_here
+
+ # Test expected value using valid instance-data key path
+ % cloud-init query -f "My AMI: {{ds.meta_data.ami_id}}"
+ My AMI: ami-0fecc35d3c8ba8d60
+
+
 .. note::
   Trying to reference jinja variables that don't exist in
-  instance-data.json will result in warnings in ``/var/log/cloud-init.log``
+  instance-data will result in warnings in ``/var/log/cloud-init.log``
   and the following string in your rendered user-data:
   ``CI_MISSING_JINJA_VAR/<your_varname>``.
 

[TheRealFalcon]

@blackboxsw , thanks that'll be a good addition. I'm not sure exactly what you're trying to show with your bottom two examples though. Particularly these two:

+ # Introspect available keys on an object in jinja
+ cloud-init query -f "{{v1.keys()}}"
+ WARNING: Could not render jinja template variables in file 'query commandline': 'invalidkey'
+ CI_MISSING_JINJA_VAR/invalidkey
+
+ # Substitute available nested keys from instance-data
+ cloud-init query -f "{{ds.meta_data.ami_id}}"

Did you lose the output from the bottom example?

[blackboxsw]

Oops I did. Updated and corrected those docs. thanks @TheRealFalcon