network v2: do not render world-readable netplan when wifi or auth config contains sensitive passwords

[ubuntu-server-builder]

This bug was originally filed in Launchpad as LP: #1981646

Launchpad details

affected_projects = ['netplan']
assignee = None
assignee_name = None
date_closed = 2023-05-02T07:34:58.316885+00:00
date_created = 2022-07-13T22:43:29.440310+00:00
date_fix_committed = 2023-05-02T07:34:58.316885+00:00
date_fix_released = 2023-05-02T07:34:58.316885+00:00
id = 1981646
importance = low
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/1981646
milestone = None
owner = chad.smith
owner_name = Chad Smith
private = False
status = fix_released
submitter = chad.smith
submitter_name = Chad Smith
tags = ['fr-2562']
duplicates = []

Launchpad user Chad Smith(chad.smith) wrote on 2022-07-13T22:43:29.440310+00:00

https://netplan.io/reference/ supports wifi password and auto client-key-password keys which should generally not be world-readable.

But, when rendering passthrough V2 network configuration, cloud-init emits a single /etc/netplan/50-cloud-init.yaml file that is world readable.

If network v2 config contains sensitive password keys it may make sense for cloud-init to either:

1. Make /etc/netplan/50-cloud-init.yaml only root-readable

• OR -

2. Write a world-readable /etc/netplan/50-cloud-init.yaml containing all keys except wifis and auth and a root-readable /etc/netplan/50-cloud-init-sensitive.yaml which would contain any security sensitive config content.

[ubuntu-server-builder]

Launchpad user Chad Smith(chad.smith) wrote on 2022-07-19T17:27:29.656900+00:00

Alternative solution to this could be if netplan.io grows a new root-only directory option that defines a schema for storing sensitive information like credentials. Not sure if this is something netplan.io would plan to grow or not. Tagging netplan.io on this bug as an FYI wishlist in case future feature work goes this direction.

The features that may be nice from netplan frm a usability standpoint:

1. documented policy that suggests chmod 600 on any netplan YAML
2. Instrumented policy in netplan generate or netplan apply that warns about world-readable files consumed which happen to contain security-related keys.
3. Ideally, sensitive YAML content root-only files wouldn't live in with world-readable content in /etc/netplan/* files. Possibly define a sensitive/security/credentials subdirectory/schema that could contain the security bits.

This is probably not the bug to file against netplan.io as it contains multiple feature request, but I wanted to track the sentiment in case that effort is becomes something desireable for netplan (and thereby affecting how cloud-init should write out sensitive files).

[ubuntu-server-builder]

Launchpad user Lukas Märdian(slyon) wrote on 2023-01-24T17:04:26.019023+00:00

Thank you for the suggestions in comment #1.

(2) has been implemented in:
canonical/netplan#300

(1) got implemented just now, to be reflected in our docs:
https://netplan.readthedocs.io/en/latest/reference.html
canonical/netplan@db04380

I'll keep this bug open as a feature request (wishlist) to consider the implementation of (3)

[ubuntu-server-builder]

Launchpad user Alex Dehnert(adehnert) wrote on 2023-05-02T02:18:38.820431+00:00

Any chance of getting the cloud-init side of this fixed? It's disconcerting to find my wifi passwords world-readable, and according to the comment at the top of the file:

This file is generated from information provided by the datasource. Changes

to it will not persist across an instance reboot.

That suggests I can't just fix the permissions and leave it alone. (OTOH, actually changing that file doesn't seem to have my changes, to either permissions or content, overwritten.)

[ubuntu-server-builder]

Launchpad user James Falcon(falcojr) wrote on 2023-05-02T07:34:50.931588+00:00

The cloud-init side of this is is available on Ubuntu 23.04+. Older releases will not see this functionality as to not break backwards compatibility.

Change landed in #1891 .

[ubuntu-server-builder]

Launchpad user Alex Dehnert(adehnert) wrote on 2023-05-02T19:45:42.929502+00:00

Thanks!