Harden Jinja template rendering with sandboxing

[tcoatswo]

Summary

Harden cloud-init Jinja template rendering by switching to a sandboxed Jinja environment.

Changes

• replace direct jinja2.Template rendering with SandboxedEnvironment
• handle SecurityError in the Jinja payload handler so unsafe templates are ignored cleanly
• add unit regressions covering unsafe attribute access in templater and handler paths

Verification

• reproduced the pre-fix behavior directly in Python: template expressions could access class, mro, and subclasses
• verified post-fix behavior directly in Python: unsafe attribute access is blocked, and handler rendering returns None with a warning
• I could not run the repo pytest suite on this host because the Python environment here does not have the pytest module installed

[blackboxsw]

Thank you for this submission and increasing the security posture for cloud-init's jinja2 template handling. Integration tests look happy with this approach. Some things we'll need on this PR:

• tox -e do_format

It looks like the sandboxedenvironment has been in Jinja2 for.... ever. So we don't have to worry about backward compatibility issues.

Requesting minor changes to ensure CI passes.

[blackboxsw]

Let's resolve conflicts in this PR and get CI passing on this please.

[blackboxsw]

Note due to 473fa33 we are no longer allowing jinja2 to be an optional runtime dependency within try/except ImportError clauses. This is primary cause for the current merge conflicts.

[holmanb]

@tcoatswo Any updates?

[tcoatswo]

@tcoatswo Any updates?

Updated.

[holmanb]

@tcoatswo The CLA job is failing.

[tcoatswo]

Squashed the commits to resolve the CLA issue. Let me know if there's anything else!

[blackboxsw]

@tcoatswo, changeset looks good thanks for resolving the merge conflicts. Our CLA service may not have received your CLA signing for the github username: tcoatswo. As the CLA service continues to report false for a github_username check which is what is rejecting this PR. Is it possible that the CLA was submitted under a different username?

curl https://cla.canonical.com/cla/check?github_usernames=tcoatswo
{"emails":{},"github_usernames":{"tcoatswo":false},"launchpad_usernames":{}}

[blackboxsw]

Updated changes look good and conflicts resolved. Thanks @tcoatswo, just awaiting CI run.

I think we just need confirmation that the CLA was signed or an understanding about why CLA service is rejecting this github username.

[tcoatswo]

I've updated the commit author email to tyler@coatsworth.me which should be linked to the signed CLA. Since the commit email changed, it looks like the CI checks are currently requiring maintainer approval to run. Could you please approve the workflow run so we can verify if the CLA check passes now? Thanks!

[tcoatswo]

Apologies for the back-and-forth! I realized I hadn't actually signed the CLA yet. I just created my account, signed the agreement, and linked my GitHub/email (tyler@coatsworth.me). The CLA check should pass now—could you please re-trigger the CI run when you have a moment? Thanks again for your patience!

[blackboxsw]

Thank you much @tcoatswo for the quick resolution here. CLA is happy and so are we.
let's ship it.